Issue 4056: Remove restrictions (ftamftp-ftf) Source: Siemens AG (Dr. Alan Burger, ) Nature: Uncategorized Issue Severity: Summary: 10. Currently, it is mandatory that the source and target File Transfer Sessions are using the same protocol, e.g., both FTAM or both FTP. It would be nice if this restriction were removed. If an implementation of the Gateway supports both protocols, the gateway could use one protocol to copy the file from the source file system to local storage, and then use the other protocol to copy it from local storage to the target file system. Resolution: rejected Revised Text: Actions taken: November 15, 2000: received issue Discussion: Rationale for Rejection There were 4 abstain and 5 to close without action (reject). The introduction of a corba interface for file transfer to resolve issue 3821 addresses the concern of this issue. End of Annotations:===== `10. Currently, it is mandatory that the source and target File Transfer Sessions are using the same protocol, e.g., both FTAM or both FTP. It would be nice if this restriction were removed. If an implementation of the Gateway supports both protocols, the gateway could use one protocol to copy the file from the source file system to local storage, and then use the other protocol to copy it from local storage to the target file system. Date: Wed, 23 May 2001 14:42:12 +1000 From: Ted McFadden To: ftamftp-ftf@omg.org Subject: Issue 4056 Comment Message-ID: <20010523144212.F27054@iona.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0i Content-Type: text/plain; charset=us-ascii X-UIDL: SSp!!L40!!jKcd9hMP!! Hi, Whether an implementation uses an FTP, FTAM, or anything else as a backend does not affect interoperability. Both implementations must use the same transfer protocol, which at the moment is a TCP socket with FTP style semantics. Issue 3821 deals with removing the restriction of the same transfer protocol so I am ok with closing this one. IONA intends to vote YES to close the issue without further action. Cheers, Ted -- Ted McFadden ted.mcfadden@iona.com IONA Total Business Integration (TM) Suite 4, 8 Martha St. +61-7-3324-9633 Camp Hill, Brisbane, 4169, QLD. Australia Date: Wed, 23 May 2001 15:30:06 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ted McFadden CC: ftamftp-ftf@omg.org Subject: Re: Issue 4056 Comment References: <20010523144212.F27054@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Ae#e9#P"!!J$G!!pK3e9 I am not sure what point you are making. If the server sends usign FTAM and the client expects FTP it will not work. FTP uses ip address and tcp port. FTAM uses presentation address (nsap address plus t-selector and s-selector. These cannot be mixed. Tom rutt Ted McFadden wrote: > > Hi, > > Whether an implementation uses an FTP, FTAM, or anything else as > a backend does not affect interoperability. > > Both implementations must use the same transfer protocol, which at the > moment is a TCP socket with FTP style semantics. > > Issue 3821 deals with removing the restriction of the same transfer > protocol so I am ok with closing this one. > > IONA intends to vote YES to close the issue without further action. > > Cheers, > > Ted > > -- > Ted McFadden ted.mcfadden@iona.com > IONA Total Business Integration (TM) > Suite 4, 8 Martha St. +61-7-3324-9633 > Camp Hill, Brisbane, 4169, QLD. Australia Date: Fri, 25 May 2001 16:12:11 +1000 From: Ted McFadden To: Tom Rutt Cc: Ted McFadden , ftamftp-ftf@omg.org Subject: Re: Issue 4056 Comment Message-ID: <20010525161211.A17590@iona.com> References: <20010523144212.F27054@iona.com> <3B0C0FBE.47DD3870@lucent.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0i In-Reply-To: <3B0C0FBE.47DD3870@lucent.com>; from terutt@lucent.com on Wed, May 23, 2001 at 03:30:06PM -0400 Content-Type: text/plain; charset=us-ascii X-UIDL: 'f~!!%b3e9mf6e9VFad9 On Wed, May 23, 2001 at 03:30:06PM -0400, Tom Rutt wrote: > I am not sure what point you are making. > > If the server sends usign FTAM and the client expects FTP it will not work. > > FTP uses ip address and tcp port. > > FTAM uses presentation address (nsap address plus t-selector and s-selector. > > These cannot be mixed. > > Tom rutt > Hi, I am in agreement with you that the protocol used to do the transfer must be the same. If corba becomes a mandatory supported protocol by resolving issue 3821, then implementations will always have at least one common transfer protocol. This would address the request made in issue 4056, to allow FTAM and FTP based implementations to interoperate, which is why I want to vote YES to close it. If people think its more appropriate to hold this issue until after the vote concluded for 3821, I won't object. Cheers, Ted > > Ted McFadden wrote: > > > > Hi, > > > > Whether an implementation uses an FTP, FTAM, or anything else as > > a backend does not affect interoperability. > > > > Both implementations must use the same transfer protocol, which at > the > > moment is a TCP socket with FTP style semantics. > > > > Issue 3821 deals with removing the restriction of the same > transfer > > protocol so I am ok with closing this one. > > > > IONA intends to vote YES to close the issue without further > action. > > > > Cheers, > > > > Ted > > > > -- > > Ted McFadden ted.mcfadden@iona.com > > IONA Total Business Integration (TM) > > Suite 4, 8 Martha St. +61-7-3324-9633 > > Camp Hill, Brisbane, 4169, QLD. Australia -- Ted McFadden ted.mcfadden@iona.com IONA Total Business Integration (TM) Suite 4, 8 Martha St. +61-7-3324-9633 Camp Hill, Brisbane, 4169, QLD. Australia Date: Fri, 25 May 2001 18:10:53 +1000 From: Ted McFadden To: ftamftp-ftf@omg.org Subject: File Transfer Protocols Message-ID: <20010525181053.A672@iona.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0i Content-Type: text/plain; charset=us-ascii X-UIDL: M/Wd9E*J!!OLo!!Sm?e9 Hi, Issue 4056 got me thinking again about transfer protocols. One thing that has bothered me a great deal about the spec is that it is not defined what it means to use a particular transport protocol, and no mention of implementations using ftam or ftp. The only place the specification illustrates a file transfer or discusses a value of ProtocolStruct it is shown as {"TCP/IP" , "255.255.255.255:8001"}. The example given is just doing a simplistic (and problematic) socket blast. What does it mean if a supported protocol is "ftam" or "ftp"? With our modified IDL prototype an ftp server's control connection can be hidden behind the "FileTransferSession" and the ftp server's data socket gets exposed directly to the client as a "TCP/IP" protocol. So although this case is actually using "ftp", from the client's perspective the transfer is not ftp, just a "TCP/IP" socket that data can be streamed to/from. I think the modified IDL I posted earlier, could handle having a client and server negotiate all the details of an ftam or ftp transfer, including login , the transfer, and terminating the connection if required. I don't see how this could ever be done with the current IDL, or maybe this was not the intention? Any comments would be appreciated as we really clarify the spec, nailing down how transfers are set up and protcol specific information is exchanged. Cheers, Ted -- Ted McFadden ted.mcfadden@iona.com IONA Total Business Integration (TM) Suite 4, 8 Martha St. +61-7-3324-9633 Camp Hill, Brisbane, 4169, QLD. Australia Date: Fri, 25 May 2001 18:10:53 +1000 From: Ted McFadden To: ftamftp-ftf@omg.org Subject: File Transfer Protocols Message-ID: <20010525181053.A672@iona.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0i Content-Type: text/plain; charset=us-ascii X-UIDL: M/Wd9E*J!!OLo!!Sm?e9 Hi, Issue 4056 got me thinking again about transfer protocols. One thing that has bothered me a great deal about the spec is that it is not defined what it means to use a particular transport protocol, and no mention of implementations using ftam or ftp. The only place the specification illustrates a file transfer or discusses a value of ProtocolStruct it is shown as {"TCP/IP" , "255.255.255.255:8001"}. The example given is just doing a simplistic (and problematic) socket blast. What does it mean if a supported protocol is "ftam" or "ftp"? With our modified IDL prototype an ftp server's control connection can be hidden behind the "FileTransferSession" and the ftp server's data socket gets exposed directly to the client as a "TCP/IP" protocol. So although this case is actually using "ftp", from the client's perspective the transfer is not ftp, just a "TCP/IP" socket that data can be streamed to/from. I think the modified IDL I posted earlier, could handle having a client and server negotiate all the details of an ftam or ftp transfer, including login , the transfer, and terminating the connection if required. I don't see how this could ever be done with the current IDL, or maybe this was not the intention? Any comments would be appreciated as we really clarify the spec, nailing down how transfers are set up and protcol specific information is exchanged. Cheers, Ted -- Ted McFadden ted.mcfadden@iona.com IONA Total Business Integration (TM) Suite 4, 8 Martha St. +61-7-3324-9633 Camp Hill, Brisbane, 4169, QLD. Australia Date: Sat, 26 May 2001 15:28:19 +1000 From: Ted McFadden To: Juergen Boldt Subject: Re: File Transfer Protocols / not for issue archive Message-ID: <20010526152819.A4591@iona.com> References: <20010525181053.A672@iona.com> <4.3.2.7.2.20010525103716.04b54100@emerald.omg.org> Mime-Version: 1.0 X-Mailer: Mutt 1.0i In-Reply-To: <4.3.2.7.2.20010525103716.04b54100@emerald.omg.org>; from juergen@omg.org on Fri, May 25, 2001 at 10:38:02AM -0400 Content-Type: text/plain; charset=us-ascii X-UIDL: `Kh!!n2Vd9-0Oe93`Ge9 Status: RO On Fri, May 25, 2001 at 10:38:02AM -0400, Juergen Boldt wrote: > Ted, > > > is this part of the 4056 thread or should this become a new issue ...or > nothing at all ?? > Hi Juergen, It doesn't need to be part of an issue, I'm just trying to get some badly needed discussion going on the ftamftp list. Thanks, Ted > -Juergen > > At 06:10 PM 5/25/2001 +1000, you wrote: > >Hi, > > > >Issue 4056 got me thinking again about transfer protocols. > > > >One thing that has bothered me a great deal about the spec is that > >it is not defined what it means to use a particular transport > >protocol, and no mention of implementations using ftam or ftp. > > > >The only place the specification illustrates a file transfer or > >discusses a value of ProtocolStruct it is shown as {"TCP/IP" , > >"255.255.255.255:8001"}. The example given is just doing a simplistic > >(and problematic) socket blast. > > > >What does it mean if a supported protocol is "ftam" or "ftp"? > > > >With our modified IDL prototype an ftp server's control connection can > >be hidden behind the "FileTransferSession" and the ftp server's data > >socket gets exposed directly to the client as a "TCP/IP" protocol. > > > >So although this case is actually using "ftp", from the client's > >perspective the transfer is not ftp, just a "TCP/IP" socket that data > >can be streamed to/from. > > > >I think the modified IDL I posted earlier, could handle having a client > >and server negotiate all the details of an ftam or ftp transfer, > >including login , the transfer, and terminating the connection if required. > > > >I don't see how this could ever be done with the current IDL, or maybe > >this was not the intention? > > > >Any comments would be appreciated as we really clarify the spec, > >nailing down how transfers are set up and protcol specific information > >is exchanged. > > > >Cheers, > > > >Ted > > > >-- > >Ted McFadden ted.mcfadden@iona.com > >IONA Total Business Integration (TM) > >Suite 4, 8 Martha St. +61-7-3324-9633 > >Camp Hill, Brisbane, 4169, QLD. Australia > > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-781 444 0404 ext. 132 > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > Needham, MA 02494, USA Email: juergen@omg.org > URL: www.omg.org > > > > ================================================================ -- Ted McFadden ted.mcfadden@iona.com IONA Total Business Integration (TM) Suite 4, 8 Martha St. +61-7-3324-9633 Camp Hill, Brisbane, 4169, QLD. Australia Date: Wed, 30 May 2001 12:46:31 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ted McFadden CC: ftamftp-ftf@omg.org Subject: Re: File Transfer Protocols References: <20010525181053.A672@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: =>'!!&R`d9eWod9_o!"! This is my understanding of how it is supposed to work: The client opens two file transfer sessions, one on the source virtual file system and the other on the destination virtual file system. The client then uses the source file transfer session directory to locate the object reference for the source file. The client then creates a new file on the destination file transfer session. The client invokes transfer on the source file transfer session. The implementation of the source file transfer session would likely use the destination file reference to determine the destination file transfer session, and then query its supported protocols. The client implementation would then invoke transfer on the destination file transfer session, which could also query the source file transfer session for its supported protocols. It then would be in a ready state for the source file transfer session to use the file transfer protocol itself to set up a file transfer connection with the server represented by the destination file transfer session. This is a loose negotiation, in that the destination file transfer session, if it supports more than one protocol in common with the source fts, does not know which protocol the source will use until the source actuallly sets up the connection using that protocol. Thus the destination may have to "listen" on more than one protocol port for the impending connection request from the source. However, since the destination file transfer sessions may be different in successive transfer invocations on a source fts, the loose negotiation may pick a different protocol for each successive file transfer to different destination fts. Thus I do not see how a file transfer session may be limited to one protocol, so I do not understand the issue regarding more than one protocol on a file transfer session. I think this needs further discussion before a final resolution is decided. Tom Rutt (thru the file attribute) and Ted McFadden wrote: > > Hi, > > Issue 4056 got me thinking again about transfer protocols. > > One thing that has bothered me a great deal about the spec is that > it is not defined what it means to use a particular transport > protocol, and no mention of implementations using ftam or ftp. > > The only place the specification illustrates a file transfer or > discusses a value of ProtocolStruct it is shown as {"TCP/IP" , > "255.255.255.255:8001"}. The example given is just doing a simplistic > (and problematic) socket blast. > > What does it mean if a supported protocol is "ftam" or "ftp"? > > With our modified IDL prototype an ftp server's control connection can > be hidden behind the "FileTransferSession" and the ftp server's data > socket gets exposed directly to the client as a "TCP/IP" protocol. > > So although this case is actually using "ftp", from the client's > perspective the transfer is not ftp, just a "TCP/IP" socket that data > can be streamed to/from. > > I think the modified IDL I posted earlier, could handle having a client > and server negotiate all the details of an ftam or ftp transfer, > including login , the transfer, and terminating the connection if required. > > I don't see how this could ever be done with the current IDL, or maybe > this was not the intention? > > Any comments would be appreciated as we really clarify the spec, > nailing down how transfers are set up and protcol specific information > is exchanged. > > Cheers, > > Ted > > -- > Ted McFadden ted.mcfadden@iona.com > IONA Total Business Integration (TM) > Suite 4, 8 Martha St. +61-7-3324-9633 > Camp Hill, Brisbane, 4169, QLD. Australia -- ---------- Tom Rutt Tel: +1 732 949 7862 Global Strategic Standards Fax: +1 732 949 1192 Lucent Technologies terutt@lucent.com Date: Wed, 30 May 2001 14:17:51 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ted McFadden , ftamftp-ftf@omg.org Subject: Re: File Transfer Protocols References: <20010525181053.A672@iona.com> <3B1523E7.3591CAB6@lucent.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ~5j!!,J/e97#Ge9Q0i!! > Ted McFadden wrote: > > > > Hi, > > > > Issue 4056 got me thinking again about transfer protocols. > > > > One thing that has bothered me a great deal about the spec is that > > it is not defined what it means to use a particular transport > > protocol, and no mention of implementations using ftam or ftp. > > > > The only place the specification illustrates a file transfer or > > discusses a value of ProtocolStruct it is shown as {"TCP/IP" , > > "255.255.255.255:8001"}. The example given is just doing a simplistic > > (and problematic) socket blast. > > > > What does it mean if a supported protocol is "ftam" or "ftp"? > > > > With our modified IDL prototype an ftp server's control connection can > > be hidden behind the "FileTransferSession" and the ftp server's data > > socket gets exposed directly to the client as a "TCP/IP" protocol. > > > > So although this case is actually using "ftp", from the client's > > perspective the transfer is not ftp, just a "TCP/IP" socket that data > > can be streamed to/from. > > > > I think the modified IDL I posted earlier, could handle having a client > > and server negotiate all the details of an ftam or ftp transfer, > > including login , the transfer, and terminating the connection if required. > > I am concerned with details of the modified IDL. In particular: interface OctetIteratorEndPoint: TransferEndPoint { FileOctetIterator get_iterator() raises(TransferError); Having the corba based protocol as a derived interfaces is not my idea of making it a new peer protocol for the end points to use. I was thinking that the CORBA Iterator protocol would be its own protocol, with the Object reference forobtaining the iterator being the protocol address for that corba protocol type. The endpoints could be established by the file transfer session rather than by each file. The mechanisms for "go to listen" and "connectToPeer and setPeer flow should work for ftam, ftp and the new corba iterator protocol in a uniform manner. Also, I do not think the that term flow should be used, as it will be confused with the stream interface concept of flow. A connection id would suffice. However, I do believe that the existing spec has a negotiation that is underspecified. On the other hand the new IDL seems to introduce inconsistencies in the way the API is used for the corba protocol over ftam and ftp. > > I don't see how this could ever be done with the current IDL, or maybe > > this was not the intention? > > > > Any comments would be appreciated as we really clarify the spec, > > nailing down how transfers are set up and protcol specific information > > is exchanged. > > > > Cheers, > > > > Ted > > > > -- > > Ted McFadden ted.mcfadden@iona.com > > IONA Total Business Integration (TM) > > Suite 4, 8 Martha St. +61-7-3324-9633 > > Camp Hill, Brisbane, 4169, QLD. Australia > > -- > ---------- > Tom Rutt Tel: +1 732 949 7862 > Global Strategic Standards Fax: +1 732 949 1192 > Lucent Technologies terutt@lucent.com -- ---------- Tom Rutt Tel: +1 732 949 7862 Global Strategic Standards Fax: +1 732 949 1192 Lucent Technologies terutt@lucent.com Date: Thu, 31 May 2001 10:51:31 +1000 (EST) From: Michi Henning To: Tom Rutt cc: Ted McFadden , ftamftp-ftf@omg.org Subject: Re: File Transfer Protocols In-Reply-To: <3B15394F.6F11C495@lucent.com> Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Xa8!!4nI!!]2?!!$Dp!! On Wed, 30 May 2001, Tom Rutt wrote: > The endpoints could be established by the file transfer session rather than by > each file. I don't think so, because then you couldn't transfer several files in parallel. > The mechanisms for "go to listen" and "connectToPeer and setPeer flow should > work for ftam, ftp and the new corba iterator protocol in a uniform manner. > Also, I do not think the that term flow should be used, as it will be confused > with the stream interface concept of flow. A connection id would suffice. Instead of an object? That de-encapsulates how connections are identified, so I'm not keen on that. > On the other hand the new IDL seems to introduce > inconsistencies > in the way the API is used for the corba protocol over ftam and ftp. Exactly what inconsistencies? Cheers, Michi. -- Michi Henning +61 7 3324 9633 Chief CORBA Scientist +61 4 1118 2700 (mobile) IONA Technologies +61 7 3324 9799 (fax) Total Business Integration http://www.ooc.com.au/staff/michi Date: Thu, 31 May 2001 11:46:57 +1000 From: Ted McFadden To: Tom Rutt Cc: Ted McFadden , ftamftp-ftf@omg.org Subject: Re: File Transfer Protocols Message-ID: <20010531114657.C18795@iona.com> References: <20010525181053.A672@iona.com> <3B1523E7.3591CAB6@lucent.com> <3B15394F.6F11C495@lucent.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0i In-Reply-To: <3B15394F.6F11C495@lucent.com>; from terutt@lucent.com on Wed, May 30, 2001 at 02:17:51PM -0400 Content-Type: text/plain; charset=us-ascii X-UIDL: 4B3!!j9Ge9j8Ce9#"8!! On Wed, May 30, 2001 at 02:17:51PM -0400, Tom Rutt wrote: > > [snip] > I am concerned with details of the modified IDL. > > In particular: > > > interface OctetIteratorEndPoint: TransferEndPoint { > FileOctetIterator get_iterator() > raises(TransferError); > > Having the corba based protocol as a derived interfaces is not my idea of > making it a new peer protocol for the end points to use. > Hi Tom, Thanks for give the prototype IDL a good look over. I am expecting that more than a few changes will be required. You are right there isn't a need for OctetIteratorEndPoint to derive from TransferEndPoint, it was just an artifact of the prototype implementation. > I was thinking that the CORBA Iterator protocol would be its own protocol, > with the Object reference forobtaining the iterator being the protocol address > for that corba protocol type. > Yes. I think this is cleaner and more consistent. This has almost no impact on the prototype we have, it just changes a narrow to a string_to_object/narrow. > The endpoints could be established by the file transfer session rather than by > each file. > That's probably true, but I'm still inclined to put end point creation for a file transfer as an operation on File. I'll think about some implementation ramifications before commenting further. > The mechanisms for "go to listen" and "connectToPeer and setPeer flow should > work for ftam, ftp and the new corba iterator protocol in a uniform manner. Yes. In our prototype the same code block is used for file transfer regardless of protocol, (even with the derivation of OctetIteratorEndPoint from TransferEndPoint) > Also, I do not think the that term flow should be used, as it will be confused > with the stream interface concept of flow. A connection id would suffice. > I'm not attached to the term flow. I did want it to be clear initially that the ideas were borrowed from the A/V spec. As long as its type can represent whatever the protocol might need (as string does). > However, I do believe that the existing spec has a negotiation that is > underspecified. On the other hand the new IDL seems to introduce > inconsistencies > in the way the API is used for the corba protocol over ftam and ftp. > As noted the derivation of the corba transfer interface from TransferEndPoint is unecessary. We want the transfer set up and control to be identical for all protocols. I've pasted a snip of our current prototype code showing consistent use for multiple protocols. (IDL is slightly behind what I posted.) (This code allows for the advertised protocols to optionally denote whether they have restrictions on passive or active connection. This is required to address issue #4229 about firewalls) --------------------------------------------------------------------------- This is the File interface transfer code from our prototype used for corba & tcp, and is called by File transfer/append/insert.... ... // Helper to pick compatible protocols from sender /receiver // ProtocolPair transferPair = new ProtocolPair(get_end_point_protocols(), dest.get_end_point_protocols()); String sourceFlow = transferPair.getSourceProtocol(); String sinkFlow = transferPair.getSinkProtocol(); TransferEndPoint sourcePoint = create_end_point(EndPointType.source, FilePos.begin, 0, sourceFlow); TransferEndPoint sinkPoint = dest.create_end_point(EndPointType.sink, tpos, tfileOffset, sinkFlow); TransferEndPoint passivePoint; TransferEndPoint activePoint; String activeFlow; String passiveFlow; if (transferPair.getSinkRole() == ProtocolPair.PASSIVE) { passivePoint = sinkPoint; // receiver listens activePoint = sourcePoint; // sender connects activeFlow = sourceFlow; } else { passivePoint = sourcePoint; // sender listens activePoint = sinkPoint; // receiver connects activeFlow = sinkFlow; } // Connect active and passive end points // passiveFlow = passivePoint.go_to_listen(activePoint, activeFlow); activeFlow = activePoint.connect_to_peer(passivePoint, passiveFlow); passivePoint.set_peer_flow(activeFlow); sourcePoint.transfer(); -- Ted McFadden ted.mcfadden@iona.com IONA Total Business Integration (TM) Suite 4, 8 Martha St. +61-7-3324-9633 Camp Hill, Brisbane, 4169, QLD. Australia Date: Thu, 31 May 2001 12:58:35 +1000 From: Ted McFadden To: Tom Rutt Cc: Ted McFadden , ftamftp-ftf@omg.org Subject: Re: File Transfer Protocols Message-ID: <20010531125835.E18795@iona.com> References: <20010525181053.A672@iona.com> <3B1523E7.3591CAB6@lucent.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0i In-Reply-To: <3B1523E7.3591CAB6@lucent.com>; from terutt@lucent.com on Wed, May 30, 2001 at 12:46:31PM -0400 Content-Type: text/plain; charset=us-ascii X-UIDL: p^Xd9"e\!!QjFe9gJa!! On Wed, May 30, 2001 at 12:46:31PM -0400, Tom Rutt wrote: Hi, > This is my understanding of how it is supposed to work: > > The client opens two file transfer sessions, one on the source > virtual file > system and the other on the destination virtual file system. > > The client then uses the source file transfer session directory to > locate the > object reference for the source file. > > The client then creates a new file on the destination file transfer > session. > > The client invokes transfer on the source file transfer session. > The > implementation of the source file transfer session would likely use > the destination file reference to determine the destination file > transfer > session, > and then query its supported protocols. The client implementation > would then > invoke transfer on the destination file transfer session, which > could also > query the source file transfer session for its supported protocols. > It then > would be in a ready state for the source file transfer session to > use the > file transfer protocol itself to set up a file transfer connection > with the > server represented by the destination file transfer session. > Again, my problem with the spec is the complete lack of detail on using ftp or ftam as a supported protocol. Let me walk through this for what an ftp protocol transfer would have to look like using the Current IDL and see if its consistent with your view of what the spec is saying. For example, lets say I want to transfer SessionA:FileA to SessionB:FileB and session B advertises that it supports FTP, which I'm assuming would have a ProtocolStruct entry something like: FTP", "my.ftp.server.com:20". To transfer a file: // Session A's transfer implementation // SessionA.transfer_file(FileA, FileB) { // Query FileB to Find SessionB to determine ftp transfer is // available @ "my.ftp.server.com:20" // ok, first problem, where does the username / password come from? // Assume username / password are identical with the ones used for // SessionB logon so we can keep going and that ProtocolStruct contains // "name:password@my.ftp.server:20" String fileBTransferName = FileB.get_complete_name() // next line called in another thread // FileB.transfer() // make sure receiver is listening / // If simple client stubs are used, must be called // in another thread since it blocks until transfer // complete. So sender must be // MULTI-THREADED, unless // send_request/get_reply used. // // receiver is available, open ftp connection ftpConnection = ftpClient(my.ftp.server,20,name,password) ftpConnection.setPort(...)... // various ftp setups PORT / BINARY etc.... ftpConnection.put(FileA.get_complete_name()) ftpConnection.close() .... } And something similar for FTAM. Ted > This is a loose negotiation, in that the destination file transfer session, > if it supports more than one protocol in common with the source fts, does not > know which protocol the source will use until the source actuallly sets up the > connection using that protocol. Thus the destination may have to "listen" on > more > than one protocol port for the impending connection request from the source. > > However, since the destination file transfer sessions may be different in > successive transfer invocations on a source fts, the loose negotiation may > pick a different protocol for each successive file transfer to different > destination fts. Thus I do not see how a file transfer session may be > limited to one protocol, so I do not understand the issue regarding more than > one protocol on a file transfer session. > > I think this needs further discussion before a final resolution is decided. > > Tom Rutt > (thru the file attribute) and > > Ted McFadden wrote: > > > > Hi, > > > > Issue 4056 got me thinking again about transfer protocols. > > > > One thing that has bothered me a great deal about the spec is that > > it is not defined what it means to use a particular transport > > protocol, and no mention of implementations using ftam or ftp. > > > > The only place the specification illustrates a file transfer or > > discusses a value of ProtocolStruct it is shown as {"TCP/IP" , > > "255.255.255.255:8001"}. The example given is just doing a simplistic > > (and problematic) socket blast. > > > > What does it mean if a supported protocol is "ftam" or "ftp"? > > > > With our modified IDL prototype an ftp server's control connection can > > be hidden behind the "FileTransferSession" and the ftp server's data > > socket gets exposed directly to the client as a "TCP/IP" protocol. > > > > So although this case is actually using "ftp", from the client's > > perspective the transfer is not ftp, just a "TCP/IP" socket that data > > can be streamed to/from. > > > > I think the modified IDL I posted earlier, could handle having a client > > and server negotiate all the details of an ftam or ftp transfer, > > including login , the transfer, and terminating the connection if required. > > > > I don't see how this could ever be done with the current IDL, or maybe > > this was not the intention? > > > > Any comments would be appreciated as we really clarify the spec, > > nailing down how transfers are set up and protcol specific information > > is exchanged. > > > > Cheers, > > > > Ted > > > > -- > > Ted McFadden ted.mcfadden@iona.com > > IONA Total Business Integration (TM) > > Suite 4, 8 Martha St. +61-7-3324-9633 > > Camp Hill, Brisbane, 4169, QLD. Australia > > -- > ---------- > Tom Rutt Tel: +1 732 949 7862 > Global Strategic Standards Fax: +1 732 949 1192 > Lucent Technologies terutt@lucent.com -- Ted McFadden ted.mcfadden@iona.com IONA Total Business Integration (TM) Suite 4, 8 Martha St. +61-7-3324-9633 Camp Hill, Brisbane, 4169, QLD. Australia Date: Thu, 31 May 2001 13:10:02 +1000 From: Ted McFadden To: Tom Rutt Cc: Ted McFadden , ftamftp-ftf@omg.org Subject: Re: File Transfer Protocols / Issue 4056 Message-ID: <20010531131002.F18795@iona.com> References: <20010525181053.A672@iona.com> <3B1523E7.3591CAB6@lucent.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0i In-Reply-To: <3B1523E7.3591CAB6@lucent.com>; from terutt@lucent.com on Wed, May 30, 2001 at 12:46:31PM -0400 Content-Type: text/plain; charset=us-ascii X-UIDL: ij!e9@?-!!i6G!!(p^d9 On Wed, May 30, 2001 at 12:46:31PM -0400, Tom Rutt wrote: [snip] >.... > This is a loose negotiation, in that the destination file transfer session, > if it supports more than one protocol in common with the source fts, does not > know which protocol the source will use until the source actuallly sets up the > connection using that protocol. Thus the destination may have to "listen" on > more > than one protocol port for the impending connection request from the source. > > However, since the destination file transfer sessions may be different in > successive transfer invocations on a source fts, the loose negotiation may > pick a different protocol for each successive file transfer to different > destination fts. Thus I do not see how a file transfer session may be > limited to one protocol, so I do not understand the issue regarding more than > one protocol on a file transfer session. > > I think this needs further discussion before a final resolution is decided. > I need to clarify here that we're talking about 4056, right? I believe 4056 can be read to say that the problem is FileTransferSessions must support the same protocol for a particular transfer (not every transfer a session is involved in) I believe the introduction of a corba based protocol removes the problem. But if you or anyone else would like to continue active discussion on this or would prefer waiting for the outcome of 3821 (corba based transfer), it can be held open. I'll post another brief email about extending 4056 voting. Cheers, Ted > Tom Rutt > (thru the file attribute) and > > Ted McFadden wrote: > > > > Hi, > > > > Issue 4056 got me thinking again about transfer protocols. > > > > One thing that has bothered me a great deal about the spec is that > > it is not defined what it means to use a particular transport > > protocol, and no mention of implementations using ftam or ftp. > > > > The only place the specification illustrates a file transfer or > > discusses a value of ProtocolStruct it is shown as {"TCP/IP" , > > "255.255.255.255:8001"}. The example given is just doing a > simplistic > > (and problematic) socket blast. > > > > What does it mean if a supported protocol is "ftam" or "ftp"? > > > > With our modified IDL prototype an ftp server's control connection > can > > be hidden behind the "FileTransferSession" and the ftp server's > data > > socket gets exposed directly to the client as a "TCP/IP" protocol. > > > > So although this case is actually using "ftp", from the client's > > perspective the transfer is not ftp, just a "TCP/IP" socket that > data > > can be streamed to/from. > > > > I think the modified IDL I posted earlier, could handle having a > client > > and server negotiate all the details of an ftam or ftp transfer, > > including login , the transfer, and terminating the connection if > required. > > > > I don't see how this could ever be done with the current IDL, or > maybe > > this was not the intention? > > > > Any comments would be appreciated as we really clarify the spec, > > nailing down how transfers are set up and protcol specific > information > > is exchanged. > > > > Cheers, > > > > Ted > > > > -- > > Ted McFadden ted.mcfadden@iona.com > > IONA Total Business Integration (TM) > > Suite 4, 8 Martha St. +61-7-3324-9633 > > Camp Hill, Brisbane, 4169, QLD. Australia > > -- > ---------- > Tom Rutt Tel: +1 732 949 7862 > Global Strategic Standards Fax: +1 732 949 1192 > Lucent Technologies > terutt@lucent.com -- Ted McFadden ted.mcfadden@iona.com IONA Total Business Integration (TM) Suite 4, 8 Martha St. +61-7-3324-9633 Camp Hill, Brisbane, 4169, QLD. Australia Date: Thu, 31 May 2001 13:14:32 +1000 From: Ted McFadden To: ftamftp-ftf@omg.org Subject: FTAM-FTP VOTE 1 / HOLD VOTE OPEN ON 4056? Message-ID: <20010531131432.G18795@iona.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0i Content-Type: text/plain; charset=us-ascii X-UIDL: C%_d9<`Je9$W[d9iKVd9 Hi, The topic of protocols as generated some discussion. If anyone would like to see the vote on issue 4056 held open for a while longer please reply to this email. If no replies are received requesting the vote be held open, the vote on 4056 closes on Saturday June 2, 12:00AM as previously scheduled. Cheers, Ted -- Ted McFadden ted.mcfadden@iona.com IONA Total Business Integration (TM) Suite 4, 8 Martha St. +61-7-3324-9633 Camp Hill, Brisbane, 4169, QLD. Australia Date: Thu, 31 May 2001 13:17:41 +1000 From: Ted McFadden To: Juergen Boldt Subject: Ok to file this under 4056 [Re: File Transfer Protocols / Issue 4056] Message-ID: <20010531131741.H18795@iona.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0i Content-Type: text/plain; charset=us-ascii X-UIDL: ,W@e9UDf!!JY)!!>Amd9 Hi Juergen, Although this discussion didn't originally concern 4056, it has drifted into it, despite my best intentions. ;-) Please file this and any follow ups under 4056. Thanks, Ted ----- Forwarded message from Ted McFadden ----- > Date: Thu, 31 May 2001 13:10:02 +1000 > From: Ted McFadden > To: Tom Rutt > Cc: Ted McFadden , ftamftp-ftf@omg.org > Subject: Re: File Transfer Protocols / Issue 4056 > X-Mailer: Mutt 1.0i > In-Reply-To: <3B1523E7.3591CAB6@lucent.com>; from terutt@lucent.com > on Wed, May 30, 2001 at 12:46:31PM -0400 > > On Wed, May 30, 2001 at 12:46:31PM -0400, Tom Rutt wrote: > [snip] > >.... > > This is a loose negotiation, in that the destination file transfer > session, > > if it supports more than one protocol in common with the source > fts, does not > > know which protocol the source will use until the source actuallly > sets up the > > connection using that protocol. Thus the destination may have to > "listen" on > > more > > than one protocol port for the impending connection request from > the source. > > > > However, since the destination file transfer sessions may be > different in > > successive transfer invocations on a source fts, the loose > negotiation may > > pick a different protocol for each successive file transfer to > different > > destination fts. Thus I do not see how a file transfer session > may be > > limited to one protocol, so I do not understand the issue > regarding more than > > one protocol on a file transfer session. > > > > I think this needs further discussion before a final resolution is > decided. > > > > I need to clarify here that we're talking about 4056, right? I > believe > 4056 can be read to say that the problem is FileTransferSessions > must > support the same protocol for a particular transfer (not every > transfer a session is involved in) > > I believe the introduction of a corba based protocol removes the > problem. > > But if you or anyone else would like to continue active discussion > on this or would prefer waiting for the outcome of 3821 (corba based > transfer), it can be held open. I'll post another brief email about > extending 4056 voting. > > Cheers, > > Ted > > > Tom Rutt > > (thru the file attribute) and > > > > Ted McFadden wrote: > > > > > > Hi, > > > > > > Issue 4056 got me thinking again about transfer protocols. > > > > > > One thing that has bothered me a great deal about the spec is > that > > > it is not defined what it means to use a particular transport > > > protocol, and no mention of implementations using ftam or ftp. > > > > > > The only place the specification illustrates a file transfer or > > > discusses a value of ProtocolStruct it is shown as {"TCP/IP" , > > > "255.255.255.255:8001"}. The example given is just doing a > simplistic > > > (and problematic) socket blast. > > > > > > What does it mean if a supported protocol is "ftam" or "ftp"? > > > > > > With our modified IDL prototype an ftp server's control > connection can > > > be hidden behind the "FileTransferSession" and the ftp server's > data > > > socket gets exposed directly to the client as a "TCP/IP" > protocol. > > > > > > So although this case is actually using "ftp", from the client's > > > perspective the transfer is not ftp, just a "TCP/IP" socket that > data > > > can be streamed to/from. > > > > > > I think the modified IDL I posted earlier, could handle having a > client > > > and server negotiate all the details of an ftam or ftp transfer, > > > including login , the transfer, and terminating the connection > if required. > > > > > > I don't see how this could ever be done with the current IDL, or > maybe > > > this was not the intention? > > > > > > Any comments would be appreciated as we really clarify the spec, > > > nailing down how transfers are set up and protcol specific > information > > > is exchanged. > > > > > > Cheers, > > > > > > Ted > > > > > > -- > > > Ted McFadden ted.mcfadden@iona.com > > > IONA Total Business Integration (TM) > > > Suite 4, 8 Martha St. +61-7-3324-9633 > > > Camp Hill, Brisbane, 4169, QLD. Australia > > > > -- > > ---------- > > Tom Rutt Tel: +1 732 949 7862 > > Global Strategic Standards Fax: +1 732 949 1192 > > Lucent Technologies > terutt@lucent.com > > -- > Ted McFadden ted.mcfadden@iona.com > IONA Total Business Integration (TM) > Suite 4, 8 Martha St. +61-7-3324-9633 > Camp Hill, Brisbane, 4169, QLD. Australia ----- End forwarded message ----- -- Ted McFadden ted.mcfadden@iona.com IONA Total Business Integration (TM) Suite 4, 8 Martha St. +61-7-3324-9633 Camp Hill, Brisbane, 4169, QLD. Australia Date: Thu, 31 May 2001 10:31:20 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ted McFadden CC: ftamftp-ftf@omg.org Subject: Re: File Transfer Protocols / Issue 4056 References: <20010525181053.A672@iona.com> <3B1523E7.3591CAB6@lucent.com> <20010531131002.F18795@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: c`/e9Q8@e9W81!!2hmd9 With Teds resolution I can close issue 4056. The corba file transfer idl can be resolved independent of issue 4056, in my opinion. Tom Rutt Ted McFadden wrote: > > On Wed, May 30, 2001 at 12:46:31PM -0400, Tom Rutt wrote: > [snip] > >.... > > This is a loose negotiation, in that the destination file transfer session, > > if it supports more than one protocol in common with the source fts, does not > > know which protocol the source will use until the source actuallly sets up the > > connection using that protocol. Thus the destination may have to "listen" on > > more > > than one protocol port for the impending connection request from the source. > > > > However, since the destination file transfer sessions may be different in > > successive transfer invocations on a source fts, the loose negotiation may > > pick a different protocol for each successive file transfer to different > > destination fts. Thus I do not see how a file transfer session may be > > limited to one protocol, so I do not understand the issue regarding more than > > one protocol on a file transfer session. > > > > I think this needs further discussion before a final resolution is decided. > > > > I need to clarify here that we're talking about 4056, right? I believe > 4056 can be read to say that the problem is FileTransferSessions must > support the same protocol for a particular transfer (not every > transfer a session is involved in) > > I believe the introduction of a corba based protocol removes the > problem. > > But if you or anyone else would like to continue active discussion > on this or would prefer waiting for the outcome of 3821 (corba based > transfer), it can be held open. I'll post another brief email about > extending 4056 voting. > > Cheers, > > Ted > > > Tom Rutt > > (thru the file attribute) and > > > > Ted McFadden wrote: > > > > > > Hi, > > > > > > Issue 4056 got me thinking again about transfer protocols. > > > > > > One thing that has bothered me a great deal about the spec is that > > > it is not defined what it means to use a particular transport > > > protocol, and no mention of implementations using ftam or ftp. > > > > > > The only place the specification illustrates a file transfer or > > > discusses a value of ProtocolStruct it is shown as {"TCP/IP" , > > > "255.255.255.255:8001"}. The example given is just doing a simplistic > > > (and problematic) socket blast. > > > > > > What does it mean if a supported protocol is "ftam" or "ftp"? > > > > > > With our modified IDL prototype an ftp server's control connection can > > > be hidden behind the "FileTransferSession" and the ftp server's data > > > socket gets exposed directly to the client as a "TCP/IP" protocol. > > > > > > So although this case is actually using "ftp", from the client's > > > perspective the transfer is not ftp, just a "TCP/IP" socket that data > > > can be streamed to/from. > > > > > > I think the modified IDL I posted earlier, could handle having a client > > > and server negotiate all the details of an ftam or ftp transfer, > > > including login , the transfer, and terminating the connection if required. > > > > > > I don't see how this could ever be done with the current IDL, or maybe > > > this was not the intention? > > > > > > Any comments would be appreciated as we really clarify the spec, > > > nailing down how transfers are set up and protcol specific information > > > is exchanged. > > > > > > Cheers, > > > > > > Ted > > > > > > -- > > > Ted McFadden ted.mcfadden@iona.com > > > IONA Total Business Integration (TM) > > > Suite 4, 8 Martha St. +61-7-3324-9633 > > > Camp Hill, Brisbane, 4169, QLD. Australia > > > > -- > > ---------- > > Tom Rutt Tel: +1 732 949 7862 > > Global Strategic Standards Fax: +1 732 949 1192 > > Lucent Technologies terutt@lucent.com > > -- > Ted McFadden ted.mcfadden@iona.com > IONA Total Business Integration (TM) > Suite 4, 8 Martha St. +61-7-3324-9633 > Camp Hill, Brisbane, 4169, QLD. Australia -- ---------- Tom Rutt Tel: +1 732 949 7862 Global Strategic Standards Fax: +1 732 949 1192 Lucent Technologies terutt@lucent.com Date: Thu, 31 May 2001 10:38:13 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ted McFadden CC: ftamftp-ftf@omg.org Subject: Re: File Transfer Protocols References: <20010525181053.A672@iona.com> <3B1523E7.3591CAB6@lucent.com> <20010531125835.E18795@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: f"-e9fYmd98/%!!_ZZd9 Ted McFadden wrote: > > Again, my problem with the spec is the complete lack of detail on > using ftp or ftam as a supported protocol. > > Let me walk through this for what an ftp protocol transfer would > have > to look like using the Current IDL and see if its consistent with > your > view of what the spec is saying. > > For example, lets say I want to transfer SessionA:FileA to > SessionB:FileB and session B advertises that it supports FTP, which > I'm assuming would have a ProtocolStruct entry something like: FTP", > "my.ftp.server.com:20". > > To transfer a file: > > // Session A's transfer implementation > // > SessionA.transfer_file(FileA, FileB) > { > > // Query FileB to Find SessionB to determine ftp transfer is > // available @ "my.ftp.server.com:20" > > // ok, first problem, where does the username / password > come from? > // Assume username / password are identical with the ones > used for > // SessionB logon so we can keep going and that > ProtocolStruct contains > // "name:password@my.ftp.server:20" > This is a problem. Your fix would work if the session logon is > specific to ftp, but what if the session supports ftp and ftam? Also, the client orb > is exercising the FTP protocol api, not the client application. The client > application used the password for the logon, the Client orb would have to "remember" it > for your fix. > String fileBTransferName = FileB.get_complete_name() > > // next line called in another thread > // > FileB.transfer() // make sure receiver is listening / > // If simple client stubs are used, > must be called > // in another thread since it blocks > until transfer > // complete. So sender must be > // MULTI-THREADED, unless > // send_request/get_reply used. > // > > // receiver is available, open ftp connection > ftpConnection = ftpClient(my.ftp.server,20,name,password) > ftpConnection.setPort(...)... // various ftp setups PORT / > BINARY etc.... > > ftpConnection.put(FileA.get_complete_name()) > ftpConnection.close() > > .... > } > > And something similar for FTAM. > > > Ted > ---------- Tom Rutt Tel: +1 732 949 7862 Global Strategic Standards Fax: +1 732 949 1192 Lucent Technologies terutt@lucent.com Date: Thu, 31 May 2001 10:47:22 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Michi Henning CC: Ted McFadden , ftamftp-ftf@omg.org Subject: Re: File Transfer Protocols References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: "-=!!meF!!dY!e9~W6!! Michi Henning wrote: > > On Wed, 30 May 2001, Tom Rutt wrote: > > > The endpoints could be established by the file transfer session rather than by > > each file. > > I don't think so, because then you couldn't transfer several files in parallel. I can live with an endpoint per file. But it would disallow future extensions for mget type of capabilities (which cannot be done with the current api either). I just think we need to clarify the need for an endpoint per file. > > > The mechanisms for "go to listen" and "connectToPeer and setPeer flow should > > work for ftam, ftp and the new corba iterator protocol in a uniform manner. > > Also, I do not think the that term flow should be used, as it will be confused > > with the stream interface concept of flow. A connection id would suffice. > > Instead of an object? That de-encapsulates how connections are identified, > so I'm not keen on that. > I just want a different word than flow. Flow was meant to distinguish the french audio track from the english audio track from the video track in a multimedia stream. This is not the case in file transfer. So "protocol Identifer" might be a better term. I do not see Flow is not an object in the idl proposed by Ted. am I missing something? > > On the other hand the new IDL seems to introduce > > inconsistencies > > in the way the API is used for the corba protocol over ftam and > > ftp. > > Exactly what inconsistencies? Ted has already stated he is willing to get such consistency. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3324 9633 > Chief CORBA Scientist +61 4 1118 2700 (mobile) > IONA Technologies +61 7 3324 9799 (fax) > Total Business Integration > http://www.ooc.com.au/staff/michi -- ---------- Tom Rutt Tel: +1 732 949 7862 Global Strategic Standards Fax: +1 732 949 1192 Lucent Technologies terutt@lucent.com