Issue 4227: Cannot transfer files if Files have same associated_session                                                                                                                                             (ftamftp-ftf)
Source: DSTC (Mr. Ted McFadden, mcfadden@dstc.edu.au)
Nature: Uncategorized Issue
Severity: 
Summary: This issue concerns the operation:
      FileTransferSession::transfer(in File src, in File dest)

and the associated operations append and insert.

As described in section 4.5.2, in the transfer implementation, the
FileTransferSession must first determine whether it is associated with
the src or dest File in order to set up an active or passive
connection.

If it is the source, it sets up an active connection and then calls
`transfer' again on the destination File's associated_session.
Unfortunately, when both the src and dest files have the same_session,
a FileTransferSession will always consider itself the source and
unwanted recursion will result.

The spec could say its forbidden to transfer files associated with the
same FileTransferSession but this is extreme. 

It is also problematic to guarantee an implementation can detect this
situation, as the FileTransferSession interface has no identity
operations and a false return from is_equivalent is inconclusive. (The
is_equivalent problem is also raised in Issue 4183).

As with issue 4183, this issue could be resolved by not using the same
transfer method to both initiate sending and receiving of data.

Resolution: The resolution for issues 4177, and 4209 resolves this issue.
Revised Text: The resolution for issues 4177, and 4209 resolves this issue.
Actions taken:
March 21, 2001: received issue
Discussion: 

End of Annotations:=====
Date: Wed, 21 Mar 2001 16:23:10 +1000
From: Ted McFadden <ted.mcfadden@iona.com>
To: issues@omg.org
Subject: ftamftp-ftf issue: Cannot transfer files if Files have same
associated_session
Message-ID: <20010321162310.A26849@iona.com>
Mail-Followup-To: issues@omg.org
Mime-Version: 1.0
X-Mailer: Mutt 1.0i
Content-Type: text/plain; charset=us-ascii
X-UIDL: 55^!!$Yjd9DBY!!LH!e9

Hi,

ftamftp-ftf issue: Cannot transfer files if Files have same
associated_session
------------------------------------------------------------------------------

This issue concerns the operation:
      FileTransferSession::transfer(in File src, in File dest)

and the associated operations append and insert.

As described in section 4.5.2, in the transfer implementation, the
FileTransferSession must first determine whether it is associated with
the src or dest File in order to set up an active or passive
connection.

If it is the source, it sets up an active connection and then calls
`transfer' again on the destination File's associated_session.
Unfortunately, when both the src and dest files have the same_session,
a FileTransferSession will always consider itself the source and
unwanted recursion will result.

The spec could say its forbidden to transfer files associated with the
same FileTransferSession but this is extreme. 

It is also problematic to guarantee an implementation can detect this
situation, as the FileTransferSession interface has no identity
operations and a false return from is_equivalent is inconclusive. (The
is_equivalent problem is also raised in Issue 4183).

As with issue 4183, this issue could be resolved by not using the same
transfer method to both initiate sending and receiving of data.


-- 
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

Date: Thu, 19 Apr 2001 11:45:52 +1000
From: Ted McFadden <ted.mcfadden@iona.com>
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%<e9?7ad9S@3e9

Hi,

Issue 4183: `How does FileTransferSession determine object identity?'
and the related Issue 4227: `Cannot transfer files if Files have same
associated session' are probably the ones that we are most concerned
with, since it appears that implementations must incorrectly rely on
use of is_equivalent to determine FileTransferSession object identity.

The solution we have successfully tried is to remove all of the file
related operations from the FileTransferSession and move them to the
File interface.

I would appreciate some comments on this in the very near future so
that we can get to a specific proposal that can be voted on. There
are also several other issues that need to be discussed.

The relevant portion of the modified IDL is shown below. (This IDL
also has some other changes to address other issues which can be
discussed in other email. )

---IDL with operations moved from FileSession to File Interface -----

    interface FileSession { 
        void destroy();
    };

    // names of Files and Directories are a sequence of names
    // relative to a Directory
    // 
    typedef wstring RelativeName;
    typedef sequence<RelativeName> 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