TCP using multicast for initialization only

Question

Note: I'm not asking how to use multicast or broadcast for a whole session, only for the handshake

I was wondering whether an idea I had could be implemented in a Linux program without any changes to the kernel. Or if modifying the kernel is actually necessary, I'd like to know what files would need to be edited.

The basic idea is: the "client" sends out a TCP SYN packet to a broadcast or multicast address, then calls accept() or an equivalent to open a separate file descriptor for each SYN-ACK it gets back.

Ideally I'd like to use the modified handshake, then switch back to the standard TCP methods, but if this is impossible I don't mind using another thread and emulating it with unix domain sockets.

Answer 1

Multicast TCP is not compatible with the TCP specification. RFC 1122 section 4.2.3.10 says:

A TCP implementation MUST reject as an error a local OPEN call for an invalid remote IP address (e.g., a broadcast or multicast address).

An incoming SYN with an invalid source address must be ignored either by TCP or by the IP layer (see Section 3.2.1.3).

A TCP implementation MUST silently discard an incoming SYN segment that is addressed to a broadcast or multicast address.

The basic problem is that the source address of the SYN-ACK reply must match the destination address of the original SYN packet -- this is how replies are matched with the original connection request (in addition to matching the destination address to the original source address, and matching port numbers). But in order to switch to unicast after the handshake, you need to know the server's real address.

You could, I suppose, enhance the protocol to add a TCP option that contains this address. Or you could say that when the SYN is sent to a multicast group, the source address of the reply is ignored when matching -- this would mean that the port numbers alone uniquely define the multicast connection request. If you're interested in this, perhaps you should write up a specification for it, and propose it to the IETF as a protocol enhancement.

But there are already protocols used for finding servers on the network, such as Bonjour. Servers can also be listed in DNS or Active Directory. Your idea doesn't sound like it accomplishes anything that isn't already available.

Answer 2

It would definitely require significant kernel changes. It's also totally incompatible with the TCP RFC, so what you'd implement would not be TCP.

What files should be edited? The TCP kernel implementation files. But you first need to get a good understanding of how Linux's TCP works, way beyond what a Stackoverflow answer can provide.

However, why not go for a simpler solution?
Using UDP multicast, send a message to all potential partners. Each will reply, over UDP, with their IP and port number. then open regular TCP connections to all of them.

Answer 3

Making TCP have multiple clients is non-trivial task! Here are some of the reasons. First, if there are multiple receivers, then how do you keep track of what sending rate to use for whom. Second, if more than one receivers miss a set of packets, how do you retransmit those packets. Thirdly, if receivers advertise a given receiver buffer (aka flow-control), which one do you choose -- do you choose the smallest buffer advertised and let others suffer OR do you choose an average and let only some of the receivers suffer. Lastly, TCP is connection oriented so even if you hack kernel to do this, normal socket calls like send()/recv() would not know what client ot send or recieve from. You could try using sendto()/recvfrom(), but as of today, kernel normally ignores the addresses in these calls.

You might be better off building a application-layer overlay on top of TCP

Answer 4

"Multicast only for the handshake" sounds a lot like anycast. Maybe you could take a look at that. https://en.wikipedia.org/wiki/Anycast and https://www.rfc-editor.org/rfc/rfc1546