Is there a way to have RabbitMQ listen for UDP connections and put those packets into somesort of default queue which can then be pulled from by a standard client? Would ActiveMQ or ZeroMQ be better for this?
Consider using a simple proxy front for receiving incoming UDP packets and sending them off to RabbitMQ via AMQP. E.g. in Python you can setup a UDP server and then use the AMQP Pika library to speak with your RabbitMQ server.
Cheers!
Someone also built a udp-exchange plugin for rabbitMQ.
I haven't personally used this, but it seems like it would do the job for you without having to write your own udp to amqp forwarder ..
https://github.com/tonyg/udp-exchange
here's the excerpt
Extends RabbitMQ Server with support for a new experimental exchange type, x-udp.
Each created x-udp exchange listens on a specified UDP port for incoming messages, and relays them on to the queues bound to the exchange. It also takes messages published to the exchange and relays them on to a specified IP address and UDP port.
Related
I have ELB balancing TCP traffic to my Node.js processes. When ELB is balancing TCP connections it does not send the X-Forwarded-Proto header like it does with http connections. But I still need to know if the connection is using SSL/TLS so I can respond with a redirect from my Node process if it is not a secure connection.
Is there a way to make ELB send this header when balancing TCP connections?
Thanks
You can configure proxy protocol for your ELB to get connection related information. In case of HTTP the ELB adds headers telling about the client information, in case of TCP however, AWS ELB simply passes through the headers from the client without any modifications, this causes the back end server to lose client connection information as it is happening in your case.
To enable proxy control for your ELB, you will have to do it via API, there is currently no way to do it via UI.
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/enable-proxy-protocol.html
The above doc is a step-by-step guide on how to do this, I don't want to paste the same here as that information might change over time.
EDIT:
As it turns out, Amazon implements Version 1 of the proxy protocol only which does not give away SSL information. It does however give port numbers which was requested by the client and a process can be developed stating something like if the request was over port 443 then it was SSL. I don't like it as it is indirect, requires hardocoding and coordination between devops and developers... seems to be the only way for now...lets hope AWS ELB starts supporting Version 2 of the proxy protocol which does have SSL info soon.
As I understand:
A port designates a program on the server.
When we say to share a port, it actually means to have the requests processed by the same program listening on that port.
The WebSocket handshake resembles the HTTP format, so it can be understood by the server program that handles HTTP protocol. So it's OK to send the handshake request to port 80.
But after the handshake, the WebSocket data format is totally different from HTTP format, how could it still be sent to port 80? Such as via URL like below:
ws://somehost:80/chat
How does it work out?
My guess:
Does the HTTP program see that the incoming request on port 80 cannot be handled as HTTP, and then it will pass it to WebSocket program to process it. If so, what if there's some other protocol that wants to share port 80, say WebSocket2, how could HTTP program know which protocol to pass on to if there's not a way to identify the protocol being used.
ADD 1
Based on jfriend00's reply, I draw the following diagram:
So WebSocket and HTTP traffic in the same browser are actually carried out through different socket connections. Though they both start by connecting to server's port 80.
I think if the word WebSocket doesn't contain a socket in it, it will be easier to understand it as just another application level protocol over TCP protocol.
ADD 2
I refined the above diagram to below based on jfriend00's further comments.
What I want to show is how WebSocket communication and HTTP communication to the same server coexist in a browser.
ADD 3
After reading this thread, I recalled that the server port doesn't change when server accept a connection: Does the port change when a TCP connection is accepted by a server?
So the diagram should be like this:
The TCP connection for HTTP and the TCP connection for WebSocket should be using different client ports.
When a server listens on a given port, it is listening for incoming connections. When a new incoming connection arrives, it is given its own socket to run on. That socket provides the connection between the two endpoints. From then on, that socket runs completely independently from all other sockets that might also be connected.
So, one incoming http request can specify the "upgrade" header and get upgraded to webSocket and then both ends agree to talk the webSocket protocol from then on. Meanwhile, other incoming http requests without that upgrade header are treated only as normal http requests.
In case you don't quite understand how the webSocket protocol works, you can get a full look at how it connects here.
Here are the main steps:
The client requesting a webSocket connection, sends an HTTP request to the server on port 80.
That HTTP request is a perfectly legal HTTP request, but it has a header included on it Upgrade: websocket.
If the server supports the webSocket protocol, then it responds with a legal HTTP response with a 101 status code that includes a header Connection: Upgrade.
At that point, both sides then switch protocols to the webSocket protocol and all future communication on that socket is done using the data format for the webSocket frame.
Any other incoming HTTP requests that do not contain the upgrade request header are treated as normal HTTP requests.
Does the HTTP program see that the incoming request on port 80 cannot
be handled as HTTP, and then it will pass it to WebSocket program to
process it.
No, the first request IS a legal HTTP request (just with a special header in it) and the response sent back is a legal HTTP response. But, after that response, both sides switch protocols to webSocket. So a custom header is used to tell the web server that this incoming HTTP request is meant to be the first step in establishing a webSocket connection.
If so, what if there's some other protocol that wants to share port
80, say WebSocket2, how could HTTP program know which protocol to pass
on to if there's not a way to identify the protocol being used.
This upgrade mechanism could be used to support other protocols too by just specifying a different protocol name Upgrade: someOtherProtocol though I'm not aware of any others that have been standardized.
Because the browser use a new port to connect and send/receive messages to/from the server.
In my application, I have used apache HttpClient. Now I would like to monitor the request and response from the capture data transmitted by the httpclient. Is it possible to know which ports are opened by the HttpClient. I am using Linux, so can I use netstat to see which ports are open by my java application process?
You can get detailed info about connection management by turning on context logging as described here
Is it possible to have a TCP Socket server running which accepts incoming connections from WebSocket clients? I have a TCP Socket server and I'd like to be able to test this in a browser. Is this possible?
Absolutely! That is the purpose of websockify.
Of course your WebSocket client application will need to be able to implement the protocol of the TCP server. For example, noVNC is a browser VNC client that implements the RFB protocol and by using websockify it can connect to a normal TCP based VNC server.
Disclaimer: I created both websockify and noVNC
TCP and WebSocket are not the same protocol or framing, so wiring them up blindly isn't going to work. Well ... technically, websocket is an upgrade of http which is layered on ssl (optionally) which in turn is layered on tcp.
TCP can be thought of as a stream of bytes, while WebSocket is a set frames.
WebSocket frames can be any of the following:
TEXT - consists of 1 or more frames making up a single UTF8 message
BINARY - consists of 1 or more frames making up a byte array message
CONTINUATION - used by TEXT and BINARY to piece together 2 or more frames.
PING - obvious
PONG - obvious
CLOSE - request a close/disconnect of the protocol.
In short, you'd need to implement the websocket protocol framing in order to have TCP wired up to websocket. And you'll need to implement basic HTTP UPGRADE in order to reach that point.
I already have a server with port and want to write a web app to get the information form the port. Will this be possible with WebPorts?
The Client doesn't even need to talk back to the server, which is the whole point of websockets I would imagine, but since I already have the ports setup, I might be easier and cleaner to just connect and get the info without having to refresh.
WebSockets are not intended as clear TCP channels over which other existing protocols can be implemented.
WebSockets are designed to allow messages to be sent between a client and server, where an event is raised each time a message is received.
Hence a WebSocket client cannot simply connect to an existing TCP server - that server also has to speak the WebSocket protocol.
You could of course write a WebSocket-based server that does nothing but act as a proxy to existing network services.
I think you want websockify which is a WebSocket to plain TCP socket bridge/proxy. It also allows sending and receiving of binary data with the older version of the WebSocket protocol which hadn't yet added direct binary data support.
Disclaimer: I created websockify.