[Binary Transfer Control OCX Updated version with File I/O Error solved] Extremely fast
Posted: 2003-06-01
By: ArchiveBot
Viewed: 71
Filed Under:
No attachments for this post
[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.)
Original Author: Kenny Lai, Lai Ho Wa
Code
[Binary Transfer Control OCX] Extremely fast, almost NO MEMORY USE, reliable, This is an OCX version of a completely new binary transfer engine. It Last time I upload a sample to upload file using multiple winsocks and arrays This time I have changed my mind. I use chunks only, with DoEvents in all The speed is awesome. The top speed while sending the Office 2000 Disc 1 The zip file contain two part. The files in the top directory is a Using standalone OCX has an advantage that it uses multithread. The entire The demonstration program in the OCX Test directory(BinaryTransferOCXTest.vbp) 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
as easy to use as an ordinary Winsock control. Every network programmer must
use, and every one must see!
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.)
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.
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.
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.
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.
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 real 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.)
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!
Comments on this post
No comments have been added for this post.
You must be logged in to make a comment.