We're having a problem with some (possibly overzealous) firewall admins
who don't want us to use ephemeral ports on the client side of a
transfer connection. The standard says that the client should normally
use a default port for each data transfer, and I'm wondering if libcurl
can do this? I've been searching around but I'm kind of tired at this
point and I might have just missed it. If so, sorry.

The standard says:

3.2. ESTABLISHING DATA CONNECTIONS

       The mechanics of transferring data consists of setting up the data
       connection to the appropriate ports and choosing the parameters
       for transfer. Both the user and the server-DTPs have a default
       data port. The user-process default data port is the same as the
       control connection port (i.e., U). The server-process default
       data port is the port adjacent to the control connection port
       (i.e., L-1).

       The transfer byte size is 8-bit bytes. This byte size is relevant
       only for the actual transfer of the data; it has no bearing on
       representation of the data within a host's file system.

       The passive data transfer process (this may be a user-DTP or a
       second server-DTP) shall "listen" on the data port prior to
       sending a transfer request command. The FTP request command
       determines the direction of the data transfer. The server, upon
       receiving the transfer request, will initiate the data connection
       to the port. When the connection is established, the data
       transfer begins between DTP's, and the server-PI sends a
       confirming reply to the user-PI.

       Every FTP implementation must support the use of the default data
       ports, and only the USER-PI can initiate a change to non-default
       ports.

Thanks

Joe

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
Received on 2004-01-27