I am upgrading my FTP server to use SSL. I can successfully negotiate an SSL command channel in response to AUTH. I do synchronous I/O here, and all is fine. When the data channel is protected it immediately begins life as SSL. I use the same asynchronous I/O model for both SSL and non SSL modes, casting either SSLStream to a Stream, or casting the NetworkStream to a Stream to do the I/O. But when the data channel is SSL the data is arriving out of order. All bytes are always received, and the byte content is correct (just out of order).
My question is, are there special restrictions, or setup required on SSLStream to do asynchronous reads
SSLStream data out of order
Hot Topic
- Windows update reset the runtime security policy.
- Invoke event of a control virtually
- Using a converted tlb-Library in C# .NET 2005
- Use Javascript to check if client has added the domain as a Trusted Site
- xsdobjectgen and multiple XSD files
- How to access store procedure from oracle
- Sharing code between projects
- Installing VC++ .NET 2003 on Athlon 64?
- Getting 0 byte email attachment when constructing attachment using memorystream
- Text alignment in Listbox, and Textfile, for printing.
.NET Development
- ADO/SQLExpress Connection String Question
- Javascript, Web Services and WSE
- Business object design
- XML Web Service Weird Issue
- Getting service startup type (automatic/manual/disabled) through .net
- DataSet to new Access Database?
- Help on dynamicly compiling and security
- TCPListener & TCPClient Connection problems
- Setting DNS suffix through .NET?
- Path.Combine problem
SSLStream data out of order
GaryD9
Yes, the CPU loading seems to make the software more sensitive to a bug I introduced. I was queueing the disk write AFTER queueing the next socket receive. Apparently with the SSL it has more in the buffer ready to complete the next queued read and it actually completed before I had queued my original disk write. This is all working perfectly now.
Catadmin
By numbering the I/O context objects, that the data is actually being received in order. What is very curious is that I am of course also using asynchronous disk writes as these come in, and this is what is getting out of order. The bytes written to the disk are NOT being written to the file in the order the write requests were queued.
YET when the socket stream is a non-SSL NetworkStream, still with the same asynchronous I/O model, the data arrives in the disk file in the correct order.
For each pending receive I create a context object, which includes a 1K read buffer. I make 3 of these and add them to a Queue. Each time I receive I immediately queue a disk write. Then I queue another socket stream BeginRead. In the disk write completion handler I return the I/O context to the queue for further re-use.
So I am VERY careful not to reuse my read buffer until I know for sure the write has completed. But I wonder if there is some wierd effect with an extra internal layer of buffering with the SSLStream
Otherwise I am at a loss as to why it works with NetworkStream, but not SSLStream. Perhaps the additional CPU overhead of decrypting the read stream Should I NOT be able to have more than one pending BeginWrite to the disk Could it be the CPU load is revealing that multiple pending disk writes does not guarantee the data is written in the order that writes were queued
I HAD been working with a larger list of write context objects. I dynamically allocate extra contexts as the writes get behind the reads. I have had up to 90 pending disk writes with non SSL, and data was always written to the disk file correctly. Now with SSL the receives are the bottleneck, so the context queue does not grow from the original 3 allocations. I notice that for SSL sockets it pegs the CPU usage, but load is much lower with non-SSL transmissions.
- Lee
c#oder