sandy@TOVE.UMD.EDU (Sandy Murphy) (10/13/88)
I have been studying various transport protocols and the services they provide, especially TCP and ISO TP. I have a question concerning one feature in particular. In TCP, simultaneous attempts by two hosts to establish a connection will result in one connection. In ISO, the result would be two connections. I am told that some time ago (more than one year?) there was a discussion of the advantages of / need for the TCP method of handling simultaneous connections. Does anyone know of situations or applications that need or take advantage of this facility/feature/peculiarity of TCP? If and when we go to ISO will anything be broken? sandy murphy (sandy@tove.umd.edu)
CERF@A.ISI.EDU (10/13/88)
In systems which operate a distributed, common algorithm which does not use the master/slave or caller/callee model, the TCP was specifically designed to allow to processes to reach each other concurrently and wind up with a single connection. The ISO model tends to be master/slave. I do not know whether any distributed systems in the Internet take advantage of the TCP design feature but at the time of its design, TCP held symmetry to be a highly valuable characteristic. Vint Cerf
stuart@speedy.cs.wisc.edu (Stuart Friedberg) (10/14/88)
In article <[A.ISI.EDU]13-Oct-88.01:57:40.CERF> CERF@A.ISI.EDU writes: >I do not know whether any distributed systems in the Internet take >advantage of the TCP design feature but at the time of its design, >TCP held symmetry to be a highly valuable characteristic. > >Vint Cerf I am using the "active-active" connection protocol as the starting point for (re)configuring distributed programs under remote control. A "third-party" makes the decisions about who talks to whom, then instructs the workers to establish a connection. Master/slave introduces a completely unnecessary asymmetry into a peer relationship between worker programs. The "master" is the third-party manager, which doesn't have anything to do with the TCP connection itself, at all. So, we are using the symmetric variant, and I am quite thankful that the TCP design group (committee? mob? clique?) provided it. Stu Friedberg stuart@cs.wisc.edu
patterso@hardees.rutgers.edu (Ross Patterson) (10/15/88)
>I do not know whether any distributed systems in the Internet take >advantage of the TCP design feature but at the time of its design, >TCP held symmetry to be a highly valuable characteristic. > >Vint Cerf Doesn't the FTP "Three Party Model" depend on symetric, peer-peer connections? There are several FTP's out there that support Three Party, not to mention Braden & DeSchon's work on BFTP. Ross Patterson Center for Computer and Information Services Rutgers University
patterso@hardees.rutgers.edu (Ross Patterson) (10/17/88)
>I do not know whether any 20@aributed systems in the Internet take >advantag? TK TCP design feature but at the time of its design, >TCP held symmetry to be a highly valuable characteristicnet!hiVint Cerf Doesn't the FTP "Three Party Model" depend on symetric, peer-peer connections? There are several FTP's out there that support Three Party, not to mention Braden & DeSchon's work on BFTP. Ross Patterson Center for Computer and Information Services Rutgers University #! rnews 733 Path: munnari!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!n are4n!princeton!udel!mmdf From: 97331812%
barns@GATEWAY.MITRE.ORG (Bill Barns) (10/18/88)
Three party FTP doesn't depend on the symmetry of TCP connection opening. I suppose there is a kind of symmetry there, but it is not at the TCP connection handling level. Although there are two servers involved in a three party FTP operation, they are executing different state machines, so to speak; the client that sets up the three party FTP implicitly selects this "polarity" by sending the PASV command to one of the servers and not to the other one. Once this has been done, there is a specific assignment of duties implicit in the protocol. (The server which received the PASV command does only a passive open on the data connection, and the other one does an active open. There is a similar allocation of responsibility for closing the connection, subject to the same twist as in two party FTP where the sender of a file in a file-structure, stream-mode transfer always initiates the close.) My admittedly superficial reading of the BFTP RFC led me to believe that BFTP doesn't alter any of this, but rather provides a different sort of a frontend to the FTP operation. Bill Barns / MITRE-Washington / barns@gateway.mitre.org
patterso@hardees.rutgers.edu (Ross Patterson) (10/18/88)
>(The server which received the PASV command does only a passive open on >the data connection, and the other one does an active open. There is a Yes, that's right. I went back and re-read RFC959, and that's exactly what happens. 20/20 hindsight reminds me that what I suggested couldn't possibly work, since it would mean opening a connection between well-known ports on two different systems, precluding the use of three-party FTP between those systems by more than one user at a time. >My admittedly superficial reading of the BFTP RFC led me to believe that >BFTP doesn't alter any of this, but rather provides a different sort of >a frontend to the FTP operation. Yes, but it depends on the three-party model. I meant it as an illustration of why three-party FTP exists (there are a number of people out there who regard it as "hokey"). Ross Patterson Rutgers University Center for Computer and Information Services
deschon@VENERA.ISI.EDU (Annette DeSchon) (10/19/88)
Bill, You are correct. BFTP makes use of the server-server, or third party, model of FTP described in RFC 765. It does not depend on simultaneous TCP connections. To illustrate this: Using third party file transfer, or more specifically BFTP, there are three TCP connections. There is an FTP control connection between BFTP and each of the FTP servers, and a data connection between the two FTP servers. (P) indicates a passive open, and (A) indicates an active open of the TCP connection. In the case where BFTP sends the "PASV" command to the Source Host, the Destination Host opens the data connection: ------ | BFTP | |Daemon| ------ (A) (A) ^ ^ control conn. / \ control conn. v v (P) (P) ------ ----------- |Source| |Destination| | Host | | Host | | FTP |(P)<------>(A)| FTP | |Server| | Server | ------ data conn. ----------- Where BFTP sends the "PASV" command to the Destination Host, the Source Host opens the data connection: ------ | BFTP | |Daemon| ------ (A) (A) ^ ^ control conn. / \ control conn. v v (P) (P) ------ ----------- |Source| |Destination| | Host | | Host | | FTP |(A)<------>(P)| FTP | |Server| | Server | ------ data conn. ----------- The BFTP Daemon always initiates both control connections. --Annette