ecc@spice.cs.cmu.edu (Eric Cooper) (08/25/87)
Can anyone defend the usefulness of allowing simultaneous active OPENs to result in a single connection? It seems to me that a pair of would-be communicants cannot rely on this to succeed, since it would depend on the relative time at which they give the OPEN command. Suppose an implementation rejected incoming SYNs when in the SYN-SENT state, instead of entering SYN-RECEIVED. How could you ever observe that this implementation is really nonconforming, and not just faster or slower? Am I wrong? Does anyone have examples of applications that depend on this feature? Eric Cooper (ecc@spice.cs.cmu.edu) Computer Science Department Carnegie Mellon University
CERF@A.ISI.EDU (08/27/87)
Distributed systems with symmetric processes that automatically seek to link to each other (no master/slave relationship) would use the simul-OPEN style. It was designed into TCP for that purpose; I do not know, however, whether any actual applications have made use of this feature. Vint
hinden@PARK-STREET.BBN.COM.UUCP (08/27/87)
Vint, The only example I can think of is the Automated Network Management (ANM) system. It uses TCP as the base for its interprocess communication which allows it processes to be easily distributed. Bob
andre@nrc-ut.UUCP (Andre' Hut) (08/28/87)
In article <1261@spice.cs.cmu.edu> ecc@spice.cs.cmu.edu (Eric Cooper) writes: >Can anyone defend the usefulness of allowing simultaneous active OPENs to >result in a single connection? It seems to me that a pair of would-be >communicants cannot rely on this to succeed, since it would depend on the >relative time at which they give the OPEN command. > >Suppose an implementation rejected incoming SYNs when in the SYN-SENT state, >instead of entering SYN-RECEIVED. How could you ever observe that this >implementation is really nonconforming, and not just faster or slower? > >Am I wrong? Does anyone have examples of applications that depend on this >feature? yeah.. A pipe. A TCP connection can be used as a pipe if it connects to itself. This sounds wierd, but it works, and its a guaranteed simultaneous open. -- ----------------------------------------------------------------------------- sdcsvax-\ ihnp4-\ \ \ Andre' Hut sdcrdcf!psivax!nrcvax!nrc-ut!andre / / / hplabs--/ ucbvax!calma-/ / utah-gr!uplherc/ Network Research Corporation 923 Executive Park Dr. Suite C Salt Lake City, Utah 84117 -----------------------------------------------------------------------------
Mills@UDEL.EDU.UUCP (08/28/87)
Vint, The vintage Internet Message Protocol (RFC-759) uses, at least in some implementations, port 45 for both source and destination. The result is that it is readily possible that simultaneous connection attempts can result in a single synchronized connection. This was considered a feature. Dave
CERF@A.ISI.EDU (08/29/87)
A bit of history: In the earliest days of TCP design (1973-1974), we worked very hard to make sure that self-simul-syn would work (sounds vaguely self-abusive, doesn't it?). Richard Karp (not the one at Berkeley, but the one now running Reliable systems in Palo Alto) was a graduate student working on one of the first TCP programs (in BCPL). We assured him that the design really was intended to work on a self-connect but I recall his astonishment when we tried it and it, indeed, worked just as advertised. Vint Cerf
minshall@OPAL.BERKELEY.EDU (09/02/87)
Eric,
Whether "simultaneous" opens will always succeed or randomly
fail depends on how the underlying TCP service is implemented. If
the user code needs to look like this:
{
if (connect() == FAIL) {
listen();
}
}
then there is a race condition in which both sides may hang
in listen(). Side A fails to connect, but before A issues listen, side
B tries to connect and fails.
However, if the underlying TCP service allows this:
{
connect_or_listen();
}
as a primitive, then the simultaneous case seems to me to be
guaranteed to win. Note that I don't know of any underlying services
that allow the second form.
Greg Minshallkzm@ACC-SB-UNIX.ARPA.UUCP (09/03/87)
As Art Berggreen said in an earlier message, ACC has a product called SIMON which provides a TCP-based service for peer subscribers (as opposed to the more common Client/Server model). Several years ago when we were implementing this, we needed a scheme which avoided the race condition which Greg Minshall pointed out. So, we asked Jon Postel about the validity of using the primitive which Greg calls "connect_or_listen", which we call a "symmetric" (as opposed to passive or active) open. Jon said if we wanted to enhance our ULP interface like this, then fine. This single primitive requests an active open with an "automatic" fallback to passive if the active fails. When both subscribers use this primitive, the ability to fallback immediately eliminates the race condition. Keith.