During the process of upgrading my JACMail program to use SimpleSock, I ran into an issue when transferring large attachments. The program became noticeably faster using SimpleSock, but that speed caused some other issues. So I modified the SimpleSock demonstration program to test file transfers. Where you run into this issue will depend on the system you are using, as well as the other end and the network in between.
Outbound data is placed in a binary buffer, and dished out to Operating System in blocks that it can handle. On my Windows Vista, that block is 8,192 bytes, and on my Win 8.1, that block is 65,536 bytes. From there, the operating system will further break it down into the network packet size (about 1,500 bytes) before sending it out. Binary file transfer is actually simpler than formatted data transfer. Since disk I/O is buffered, as the binary data is received, it is added directly to the file.
To keep it simple, I sent out the file name in the first block, and the file data in the subsequent blocks. That required a 100 ms delay between blocks to prevent them from being added together. 10 ms worked in one direction, but not the other. Upon completion, there is also a 1 second (1000 ms) delay before issuing the Close Socket command to give the last packet time to reach it's destination.
The receiver end needs a "Downloads" sub-directory off the application directory to store the received files. The port number is entered and the "Listen for File" is clicked to put the receiver in the listen mode. On the sender end, the user selects a file to transfer using the "Get File" button. At this point, the user can optionally Base64 encode the file. If so, a ".B64" extension is added to the file name. Clicking on send establishes a connection with the destination/port, sends the file name, waits 100 ms, and then sends the file data. The receiver receives the file name and creates a file by that name in the "Downloads" directory. The subsequent file data is added to the file as it is received. When the sender closes the socket, the receiver closes the file. If the file is encoded, the received file can be decoded using the "Decode File" button. The result is stored under the original file name.
While building this demonstration program, I discovered a bug in SimpleSock in the binary "DeleteByte" function. How this escaped detection is beyond me, but I suspect that I was only dealing with single block transfers.
This demonstration program has been tested with various binary files up to 1,439,974 bytes. There is no reason that encrypted files could not be transferred as well, but the issue of key transfer has to be solved.
J.A. Coutts
Outbound data is placed in a binary buffer, and dished out to Operating System in blocks that it can handle. On my Windows Vista, that block is 8,192 bytes, and on my Win 8.1, that block is 65,536 bytes. From there, the operating system will further break it down into the network packet size (about 1,500 bytes) before sending it out. Binary file transfer is actually simpler than formatted data transfer. Since disk I/O is buffered, as the binary data is received, it is added directly to the file.
To keep it simple, I sent out the file name in the first block, and the file data in the subsequent blocks. That required a 100 ms delay between blocks to prevent them from being added together. 10 ms worked in one direction, but not the other. Upon completion, there is also a 1 second (1000 ms) delay before issuing the Close Socket command to give the last packet time to reach it's destination.
The receiver end needs a "Downloads" sub-directory off the application directory to store the received files. The port number is entered and the "Listen for File" is clicked to put the receiver in the listen mode. On the sender end, the user selects a file to transfer using the "Get File" button. At this point, the user can optionally Base64 encode the file. If so, a ".B64" extension is added to the file name. Clicking on send establishes a connection with the destination/port, sends the file name, waits 100 ms, and then sends the file data. The receiver receives the file name and creates a file by that name in the "Downloads" directory. The subsequent file data is added to the file as it is received. When the sender closes the socket, the receiver closes the file. If the file is encoded, the received file can be decoded using the "Decode File" button. The result is stored under the original file name.
While building this demonstration program, I discovered a bug in SimpleSock in the binary "DeleteByte" function. How this escaped detection is beyond me, but I suspect that I was only dealing with single block transfers.
This demonstration program has been tested with various binary files up to 1,439,974 bytes. There is no reason that encrypted files could not be transferred as well, but the issue of key transfer has to be solved.
J.A. Coutts