calvert@cs.utexas.edu (Kenneth L. Calvert) (01/30/91)
In TCP, the result of a "connect collision" (i.e., two peers "simultaneously" attempting to open a connection to the same pair of ports) is a single connection. I have two questions: 0. My impression is that the Berkeley Unix sockets interface (to TCP) precludes deliberate use of this "feature". Have I missed something? (The implementation does the right thing when SYN is received in state SYN_SENT). 1. Can anyone cite an application or higher-level protocol that makes use of (or could, if it were possible) this fact, i.e. permits users to establish connections symmetrically? I can think of one possibility: the FTP data connection, but I don't think it works that way. Don't need to do this myself -- just curious. Ken Calvert calvert@cs.utexas.edu
kasten@EUROPA.INTERLAN.COM (Frank Kastenholz) (01/31/91)
> From tcp-ip-RELAY@NIC.DDN.MIL Wed Jan 30 17:15:41 1991 > From: usc!cs.utexas.edu!calvert@ucsd.edu (Kenneth L. Calvert) > Organization: U. Texas CS Dept., Austin, Texas > Subject: connect "collisions" in TCP > Sender: tcp-ip-relay@nic.ddn.mil > To: tcp-ip@nic.ddn.mil > > > In TCP, the result of a "connect collision" (i.e., two peers > "simultaneously" attempting to open a connection to the same pair > of ports) is a single connection. I have two questions: > > 0. My impression is that the Berkeley Unix sockets interface (to TCP) > precludes deliberate use of this "feature". Have I missed something? > (The implementation does the right thing when SYN is received in state > SYN_SENT). I'm not sure what you mean by this question. This "feature" is a function of the protocol, not the interface to your local protocol implementation. The "feature" is deliberately "used" by TCP implementations to prevent there being two Transmission Control Blocks in a host for the same connection -- a state which is very bad. > 1. Can anyone cite an application or higher-level protocol that > makes use of (or could, if it were possible) this fact, > i.e. permits users to establish connections symmetrically? > I can think of one possibility: the FTP data connection, > but I don't think it works that way. Generally, the client/server model of communications that we use precludes the possibility of a "connect collision". Assuming that it was possible to cause such a thing to happen, I am not sure why one would explicitly want to do so -- the end result is the same regardless of whether there was such a "conenct collision" or not -- a full duplex connection. > > Don't need to do this myself -- just curious. > Ken Calvert > calvert@cs.utexas.edu >
MAB@CORNELLC.CIT.CORNELL.EDU (Mark Bodenstein) (02/01/91)
On 30 Jan 91 15:58:31 GMT you said: > >In TCP, the result of a "connect collision" (i.e., two peers >"simultaneously" attempting to open a connection to the same pair >of ports) is a single connection. I have two questions: > ... >1. Can anyone cite an application or higher-level protocol that >makes use of (or could, if it were possible) this fact, >i.e. permits users to establish connections symmetrically? The VMNET (NJE over TCP/IP) protocol makes use of this; VMNET servers both passively listen for connections and actively try to connect to their configured peers; simultaneous symmetric connection attempts are possible and result in a single connection. I understand that the VMNET protocol, which was crafted at Princeton University, will be documented in an RFC Real Soon Now. Mark Bodenstein (mab@cornellc.cit.cornell.edu) Cornell University
barmar@think.com (Barry Margolin) (02/01/91)
In article <9101302235.AA04289@europa.InterLan.Com> kasten@EUROPA.INTERLAN.COM (Frank Kastenholz) writes: > > From: usc!cs.utexas.edu!calvert@ucsd.edu (Kenneth L. Calvert) > > 1. Can anyone cite an application or higher-level protocol that > > makes use of (or could, if it were possible) this fact, > > i.e. permits users to establish connections symmetrically? > > I can think of one possibility: the FTP data connection, > > but I don't think it works that way. > >Generally, the client/server model of communications that we use >precludes the possibility of a "connect collision". Assuming that >it was possible to cause such a thing to happen, I am not sure why >one would explicitly want to do so -- the end result is the same >regardless of whether there was such a "conenct collision" or not -- >a full duplex connection. It's unlikely to happen with client-server protocols, but I can imagine it happening with peer-peer protocols. Most such protocols that I can think of are datagram and possibly broadcast/multicast based, rather than using TCP. One application I can think of would be the use of a long-lived TCP connection to emulate a point-to-point link. This might be specified such that a particular pair of hosts always use the same pair of port numbers, i.e. instead of a well-known server port, there would be a well-known quadruple <host1-addr,host1-port,host2-addr,host2-port> (for simplicity, both ports would probably be chosen to be the same). When a host boots, it sends out a SYNs using this well-known quad, until the connection succeeds. If the other host was up while this host was down, it will notice the out-of-sequence SYN, close its end (sending out a RST, I guess), and then try to open the connection, which should succeed using a connect collision. If both hosts were down at the same time, then when they each come up they'll start sending out SYNs, and when both are up a connection collision will occur. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
djk@sequent.uucp (Darin Klaas) (02/01/91)
calvert@cs.utexas.edu (Kenneth L. Calvert) writes: >0. My impression is that the Berkeley Unix sockets interface (to TCP) >precludes deliberate use of this "feature". Have I missed something? >(The implementation does the right thing when SYN is received in state >SYN_SENT). In fact it doesn't do the right thing (at least 4.3-tahoe doesn't) -- follow the incoming SYN ACK and you'll see that the two sides of the connection eventually SYN ACK each other for ever and ever... -- darin