Socket data out of order

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



I am using asynchronous socket receives and writing the data to a disk file. I am finding all of the data makes it to the file, but it is SLIGHTLY out of order.

The approach is to create a pool of contexts, each which has a 1K byte buffer. Then I start it all by getting a buffer from the pool, and do a BeginReceive on the socket.

In the receive completion handler I call EndReceive.
THEN get a buffer from the free pool, and I invoke BeginReceive again. If my buffer pool was exhausted I would allocate a new one, rather than stall.
THEN I invoke BeginWrite to write the just-received data to the disk file.


In the write completion handler I return the context and buffer to my buffer pool.

I am managing my buffer pool in a .NET "Queue". I protect all Enqueue and Dequeue with Synclock on the Queue object. Enqueues and Dequeues seem to have integrity, in that there are the correct number of buffer pools in the queue when the whole thing winds down.

Without the disk writing I get about 60 MBits / second maximum received on the socket. When I involve the disk writing it hunkers down to about 22 MBits / second. My pool size is initially 25 contexts/buffers, but typically grows to about 80-90 with very large and very fast transmissions.

I don't queue up multiple simultaneous socket receives. I know that doing that could easily result in EndReceives firing out of order with the data stream. But obviously I am queueing up to about 80-90 pending disk writes. But they SHOULD be queued up in the order they were received. And I understand they should then end up in the disk file in the correct order. I suspect something about this aspect of writing to the disk is what is getting the data out of order.

Can you see what I am doing wrong? Or perhaps there are some known bugs in the Framework? Maybe I need a SyncLock that entirely covers the segment of code starting with the EndReceive and ending with the BeginWrite?
.




Relevant Pages

  • Re: LVM write performance
    ... it and finally write it back to the disk. ... noop [deadline] cfq ... Writing 1 GB ... AACRAID* Controller on a Supermicro. ...
    (Debian-User)
  • Re: LVM write performance
    ... When writing to a logical volume directly through the ... you didn't mentioned what disk drive is in use in this test. ... Security Mode feature set ... WRITE_BUFFER command ...
    (Debian-User)
  • Temporary lock-up under heavy write, MegaRAID RAID-5
    ... LSI Logic MegaRAID 320-1, 64MB cache ... when writing very large files. ... disk write access, actually). ... The RAID controller is currently set to "write-through". ...
    (Debian-User)
  • Re: X-CD Roast question again please
    ... Using generic SCSI-3/mmc CD-R driver. ... Disk sub type: Medium Type A, ... ATIP start of lead in: -11318 ... writing 152 KB of pad data. ...
    (RedHat)
  • Re: efficacy of Linux w/o swap
    ... | Caching is supposed to happen, and this does not affect performance. ... that the impact starts to degrade the writing process itself. ... | Writing directly to disk will substantially decrease performance. ... Performance for the first 3/4 of an IDE disk ...
    (comp.os.linux.development.system)