Ok, so THIS is really the data channel problem.

With FTP, a SEPARATE TCP stream socket connection is made over wich the FTP server will receive data, and store the incoming bytes to a disk file. This is the "data channel". When we detect the peer has disconnected we close the data channel, and close the disk file. So every incoming byte appears in this disk file (in IMAGE mode).

My FTP service does this with a SecureSocket even when not utilizing SSL. The client never sends AUTH, so the command channel is never upgraded. The data channel is always created using the security settings of the parent command channel.

We form the data channel in either of two ways: a) create a socket using command channel security options and connect to client (non-passive) or b) create a listen socket using command channel security options, and listen for, and accept a connection from the client (passive).

All works perfection when the command channel is not upgraded to SSL. I have identical problems in both connection scenarios for the data channel, however, when attempting to make the SSL data channel.

1) I consistently find 3070 bytes of junk ahead of the real data the client transmitted. My transmitted file "PK" signature should be the first two bytes of my file, but instead they begin at position 3071.

2) The overall size of the transmission is identical. This in and of itself is not a problem, except that with the extra junk at the beginning, the end of the transmission is gone.