[Binary Transfer Control OCX] Extremely fast, almost NO MEMORY USE, reliable,
as easy to use as an ordinary Winsock control. Every network programmer must
use, and every one must see!
This is an OCX version of a completely new binary transfer engine. It
sends a 244MB file in 71 seconds and I can still work on another VB IDE without
effort! The sender control read-and-send one chunk only for each time, using
the same array of a chunk size (Optimum is 4096 bytes). Once the receiver
control receive the bytes, it builds up the file immediately. It's hard-drive
and CPU intensive, but using almost no memory! (You can monitor the memory usage
while sending file.)
| Submitted On | |
| By | Kenny Lai, Lai Ho Wa |
| Level | Advanced |
| User Rating | 4.4 (53 globes from 12 users) |
| Compatibility | VB 6.0 |
| Category | Internet/ HTML |
| World | Visual Basic |
| Archive File |
This is an OCX version of a completely new binary transfer engine. It sends a 244MB file in 71 seconds and I can still work on another VB IDE without effort! The sender control read-and-send one chunk only for each time, using the same array of a chunk size (Optimum is 4096 bytes). Once the receiver control receive the bytes, it builds up the file immediately. It's hard-drive and CPU intensive, but using almost no memory! (You can monitor the memory usage while sending file.)
Last time I upload a sample to upload file using multiple winsocks and arrays and collection of bytes. The speed is about 1600KBps. But many people complain about the memory usage that store all the bytes of a large file.
This time I have changed my mind. I use chunks only, with DoEvents in all FileIO and sending work. The sender read a chunk from file and send it immediately, while the reader build up the bytes to the target file once it get the bytes.
The speed is awesome. The top speed while sending the Office 2000 Disc 1 zip file(244 MB) is >4200KBps (32.8125Mbps). This meet the industrial standard (The maximum capacity of a small-business server is about 45Mbps, but the server administrator will definitely not allow one client to draw all the bandwidth.
The zip file contain two part. The files in the top directory is a User-Control test that I used to build the control for debug. The OCXs and Test project is inside the OCX Test directory. There's an OCX included, and the BinaryTransferOCXTest.exe use the reference of the BinaryTransferControl.ocx.
Using standalone OCX has an advantage that it uses multithread. The entire program will not be affected while the control is busing sending files. (REMARK: If you test the program on local-to-local with very large, >300MB files, the program itself may be affected as it draw all the CPU and HardDrive power to transfer and receive bytes. But in read situation, the CPU and HardDrive effort is directly depend on the network speed. That mean the engine draw and send and build up bytes ONLY when the last bytes is sent or received.)
The demonstration program in the OCX Test directory(BinaryTransferOCXTest.vbp) is well written and run smoothly. (As the screenshot show, it sends the Office2000 Disc 1 in ZIP effortlessly.) PLEASE FOLLOW THE ORDER OF CALLING METHOD STRICTLY ACCORDING TO THE DEMONSTRATION, AS THE METHODS AND EVENTS ARE HIGHLY INTERDEPENDENT!
Finally, please vote my work and give any comments, and critics.
Thank you for reading this long long article.
Kenny Lai
http://pcseries.sourceforge.net/pscode/BinaryTransferControl.zip