Issue 4183: How does transfer operation determine FileTransferSession object identity (ftamftp-ftf) Source: DSTC (Mr. Ted McFadden, mcfadden@dstc.edu.au) Nature: Uncategorized Issue Severity: Summary: From the description in Chapter 3, it is not clear how the FileTransferSession::transfer method is actually accomplished. Chapter 4 Section 4.5.1 describes the FileTransferSession examining the File reference's attributes to determine whether it is to initiate the transfer or receive the file. The initiator FileTransferSession::transfer implementation must then call transfer again on the target FileTransferSession. How, in a portable fashion, is a FileTransferSession to determine if it is the same FileTransferSession referred to in the src or dest File associated_session attribute? 1. _is_equivalent cannot be used to compare FileTransferSession or other object references as a false return is inconclusive. 2. There are no object identity operations defined on the FileTransferSession interface. 3. None of the other File attributes denote unique identity (name,complete_name, as the src and destination file names can be identical.) Requested Action: Clarify how the File's attributes allow a FileTransferSession implementation to determine File ownership. Resolution: see above Revised Text: Section 2.1.4 FileTransfer, Section 2.2.2 TransferConnection Establishment. Section 3.1.8 TransferEndPoint Interface. Actions taken: January 30, 2001: received issue Discussion: Resolution The transfer operation was overloaded and required use of is_equivalent. The IDL has been changed to make the roles of sender and receiver unambiguous. In particular, to transfer a file now, a SOURCE TransferEndPoint and a SINK TransferEndPoint are cre-ated. The TransferEndPoint interface has been added to the IDL. End of Annotations:===== Date: Wed, 31 Jan 2001 00:35:46 +1000 From: Ted McFadden To: issues@omg.org, ftamftp-ftf@omg.org Cc: tmcf@ooc.com.au Subject: ftam/ftp issue: transfer operation depends on FileTransferSession object identity Message-ID: <20010131003546.F16495@ooc.com.au> Reply-To: Ted McFadden Mail-Followup-To: issues@omg.org, ftamftp-ftf@omg.org Mime-Version: 1.0 Received: from errigal.ooc.com.au (IDENT:root@errigal.ooc.com.au [10.1.1.5]) by janus.ooc.com.au (8.9.3/8.9.3) with ESMTP id AAA08339 for ; Wed, 31 Jan 2001 00:35:46 +1000 Received: (from tmcf@localhost) by errigal.ooc.com.au (8.9.3/8.9.3) id AAA16742 for tmcf@ooc.com.au; Wed, 31 Jan 2001 00:35:46 +1000 X-Mailer: Mutt 1.0i Content-Type: text/plain; charset=us-ascii X-UIDL: m*Je9(8%!!g:Be9mMDe9 ftap/ftp issue: How does transfer operation determine FileTransferSession object identity ------------------------------------------------------------------------------------- >From the description in Chapter 3, it is not clear how the FileTransferSession::transfer method is actually accomplished. Chapter 4 Section 4.5.1 describes the FileTransferSession examining the File reference's attributes to determine whether it is to initiate the transfer or receive the file. The initiator FileTransferSession::transfer implementation must then call transfer again on the target FileTransferSession. How, in a portable fashion, is a FileTransferSession to determine if it is the same FileTransferSession referred to in the src or dest File associated_session attribute? 1. _is_equivalent cannot be used to compare FileTransferSession or other object references as a false return is inconclusive. 2. There are no object identity operations defined on the FileTransferSession interface. 3. None of the other File attributes denote unique identity (name,complete_name, as the src and destination file names can be identical.) Requested Action: Clarify how the File's attributes allow a FileTransferSession implementation to determine File ownership. Cheers, Ted -- Ted McFadden tmcf@ooc.com.au Object Oriented Concepts http://www.ooc.com Suite 4, 8 Martha St. +61-7-3324-9633 Camp Hill 4169, QLD. Australia Date: Wed, 7 Feb 2001 16:40:24 +1000 From: Ted McFadden To: Stephen Egan Cc: ftamftp-ftf@omg.org, Burger Alan , Bo_Andrin_ , "Louis-Francois Pau E-Mail\"" , "Terry Turner E-Mail\"" Subject: Re: ftamftp-ftf issues Message-ID: <20010207164024.F24790@ooc.com.au> References: <376BF7DF9F03D3118E510008C7DBA932036DD8@MCHH251E> <20010206204819.43756.qmail@web9401.mail.yahoo.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0i In-Reply-To: <20010206204819.43756.qmail@web9401.mail.yahoo.com>; from ftam_ftp@yahoo.com on Tue, Feb 06, 2001 at 12:48:19PM -0800 Content-Type: text/plain; charset=us-ascii X-UIDL: -A%!!$*=!!N3C!!5T/!! On Tue, Feb 06, 2001 at 12:48:19PM -0800, Stephen Egan wrote: > Hi, > There are a couple of points that I would like to make > on the issues raised. Hi Stephen, Thanks for commenting on these issues. I've cc'd the ftamftp-ftf on this to keep the OMG archive going. My responses are below. I would appreciate comments from others on the ftf. I still have some concerns about how different vendor's implementations will interoperate. > > #4181: This may be an implementation problem, but > when using OrbixWeb and VisiBroker with Java, > returning a null pointer as an "out" parameter within > a Holder object causes applications to crash. This > might affect returning a null (nil) reference as the > "fi" parameter as described in the last paragraph of > this issue. > I don't think there's an issue here. The text lifted from the Naming Service is not referring to the java language mapping Holder class, but the object reference for the FileIterator. In a Java implementation, the FileIteratorHolder returned from the list operation must be non-null, but its member "value" can be null. > #4183: The "_is_equivalent" operation has been used > to date by the FileTransferSession to determine > identity. This has worked without problem. I was not > aware that a "false" return is inconclusive. > Considering that a comparison returning "true" will be > between a reference and a (guaranteed) local object, > does this point still apply? > Unfortunately a false from is_equivalent is inconclusive. I don't dispute that this will work in some cases. However, it is not acceptable to force implementations to use it since it is not 100% reliable. I discussed the situation of a servant looking to use is_equivalent to determine if a reference refers to itself with others at OOC: Michi Henning and Raymond Smith (who should be on the ftamftp-ftf list now.) It is still not guaranteed. If object identity needs to be determined, there should be an operation on the interface that returns a unique identifier. This identity problem only arises because of the way the transfer operation is overloaded. I am not suggesting any IDL at this time but the need for the identity check would be removed by the addition of a FileTransferSession so the FileTransferSession role was not ambiguous: receive_transfer(File from, File to); then transfer(File from, File to) implementation would be a like: transfer(File from, File to){ // // Pick protocol, open socket etc.... // to.associated_session().receive_transfer(from, to); } Date: Thu, 19 Apr 2001 11:45:52 +1000 From: Ted McFadden To: ftamftp-ftf@omg.org Subject: Initial proposal for resolving issues 4183, 4227 Message-ID: <20010419114547.A29109@iona.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0i Content-Type: text/plain; charset=us-ascii X-UIDL: U<=e9T% Path; interface File: CosPropertyService::PropertySet { RelativeName get_name() raises (FileSystemError); Path get_path() raises (FileSystemError); void copy(in File dest) raises( TransferError); void append(in File dest) raises( TransferError); void insert(in File dest, in FileOffset offset) raises( TransferError); void rename(Path newPath) raises(FileSystemError); void remove() raises (FileSystemError); void destroy(); }; -------------------------------------------------------------------- For issues 4183, 4127 the important point is that by moving the transfer operations to the File interface, there is no longer any ambiguity about the source or destination Files. A copy is now done as (java-like): org.omg.CosFileTransfer.File fromFile = ....... org.omg.CosFileTransfer.File toFile = ....... try{ fromFile.copy(toFile); } catch(org.omg.CosFileTransfer.TransferError tError){ ... } The IDL presented below is not exactly the one we use, as we have also addressed issues 4177, 4209, 4228 and 4229. However to take things one step at a time, an implementation of copy that addresses only 4183, 4127 is illustrated below. This code is for discussion purposes only, it is incomplete and horribly defective. :-) Whereas the original spec relied on the use of is_equivalent to determine source and destination. The copy,append, and insert operations look at their toFile parameter. If it is null, they know they are to receive the file. Again, although this works, we still consider this to be a defective solution without addressing 4177, 4209, 4228 and 4229. (java-like): class RunReceiverCopy extends Thread { private org.omg.CosFileTransfer.File m_toFile; public RunReceiverCopy(org.omg.CosFileTransfer.File toFile){ m_toFile = toFile; } public run() { m_toFile.copy(null); } } class FileImpl extends org.omg.CosFileTransfer.FilePOA { .... public void copy(org.omg.CosFileTransfer.File toFile) { if (toFile != null) { // target not null, Send the File // toAddress = negotiateProtocolAddress(); // start receiver File listening // open connection and transfer data // new RunReceiverCopy(toFile).start(); transferSocket = new Socket(toAddress.getHost() toAddress.getPort()); transferSocket.write(.....source_file.getBytes(....)); } else { // toFile was null, this File is to receive // hostSocket = new ServerSocket(....,....); connection = hostSocket.accept(); ... destination_file.write(connection.read_bytes(....)); } } } -------------------------------------------------- Cheers, Ted -- Ted McFadden ted.mcfadden@iona.com Object Oriented Concepts Inc. - An IONA Company http://www.orbacus.com Suite 4, 8 Martha St. +61-7-3324-9633 Camp Hill, Brisbane, 4169, QLD. Australia