-
Notifications
You must be signed in to change notification settings - Fork 0
Home
The SocketForwarder is an application that allows you to group together incoming socket connections and forward messages between the sockets within the same group.
The SocketForwarder allows the following scenario to take place.
Lets say there are 20 socket clients that need to receive data from a single socket, instead of that single process needing to spawn listening threads and manage the connections. The SocketForwarder can be started and connected to by each of the 20 sockets + 1 for the sending socket. (There is no difference between a sending and receiving socket in practise, just for this example).
Each socket will connect and provide THE SAME groupID as their first message which will register them into the same group (details below). Once connected and registered in the same group all socket messages sent by any of these sockets to the SocketForwarder will be immediately forwarded to all other sockets in the same group.
Since a groupID is used, this means you could have several groups of sockets all connected with messages shared between the groups from the single SocketForwarder instance. Meaning sockets in group1 would only receive and have their messages sent to other sockets within group1. The same for other groups.
The way that the TCP and UDP group works is different due to the nature of UDP and it being stateless, all UDP connections are within the same "group". Whereas TCP is able to create and maintain groups since the protocol allows for active connections.
If you do need multiple UDP groups I reccommend using multiple instances of the SocketForwarder for each UDP group that you need.
While the SocketForwarder is running it is listening for incoming connection requests (for TCP) or incoming messages (for UDP).
The protocol to join a group is simple but differs slightly for TCP and UDP as outlined below.
With this approach sockets would need a way to detect whether they are connected to the SocketForwarder or not and to reconnect and send the correct prefix + group ID.
Once a TCP connection has been made the TCP socket's FIRST message to the SocketForwarder must match the following format: <new_client_prefix>. socketforwarder.new_client_prefix value. (Default: SOCKETFORWARDER-NEW:).
Example: SOCKETFORWARDER-NEW:My-Group-ID
If the prefix matches the connection will be accepted and added to the appropriate group and begin receiving messages sent by other sockets in that same group. Also any futher messages received by this socket will be forwarded to other sockets in the same group.
Otherwise if the prefix is invalid then the connection will be closed by the SocketForwarder.
Any remote connections that are closed will be detected and removed from their respective TCP group.
For UDP there is not connection step, since there is only a single UDP group per instance of the SocketForwarder its operation is much simpler.
To register a socket to the UDP group you must send a message with the following format: <new_client_prefix><receive_port>. socketforwarder.new_client_prefix value. (Default: SOCKETFORWARDER-NEW:). The assumption is that the incomming message is registering for itself so the received IP address + the "receive_port" that comes after the prefix will be saved as an address and all UDP messages will be forwarder to all stored UDP addresses.
Since the UDP protocol is connectionless, we cannot detect UDP "disconnections" so any there is no way to remove addresses from the UDP group once they have been added.
Once connected any incoming UDP packets will be forwarded to all other register UDP addresses.
Because of this, ANY UDP message (without being registered) can be received and automatically forwarded to other registered UDP addresses. This can be unsafe so please consider who has access to the SocketForwarder.
Pre-registering addresses allows you to configure for TCP, addresses to instantly accept and add to a group without the new_client_prefix message. And for UDP a list of addresses to automatically have all UDP data forwarded to them without them having to send a new_client_prefix message too.
Using the tcp.preconfig_addresses environment variable you are able to pre-register addresses and their respective group. So if an incoming connection is accepted from the listed preconfig addresses list, the connection will automatically be added to that group and begin receiving forwarded socket data from other sockets in that group without having to send the initial new_client_prefix message.
Using the udp.preconfig_addresses environment variable you can provide a list of addresses and ports that will automatically be added to the UDP group and have messages forwarded to them immediately once the application starts up without having to send the initial new_client_prefix message.