7sharp9 / flack Goto Github PK

You noted the first two received byte[] were off, though they added to 512 in the tests. The problem is that the first SocketAsyncEventArgs received a portion before the receiving SAEA. If the accept socket has no buffer, perhaps that would force all bytes into the receiving SAEA.

Are you still considering doing work on it? Or was it integrated into Frack?

Should I be considering spending time understanding this code, or Frack's code?

see:

The ReceiveAsync method can indicate the graceful termination of the virtual circuit in one of two ways that depend on whether the socket is byte stream or message oriented. For byte streams, zero bytes having been read indicates graceful closure and that no more bytes will ever be read. For message-oriented sockets, where a zero byte message is often allowable, a SocketException with the SocketAsyncEventArgs.SocketError set to the native Winsock WSAEDISCON error code (10101) is used to indicate graceful closure. In any case, a SocketException with the SocketAsyncEventArgs.SocketError set to the native Winsock WSAECONNRESET error code (10054) indicates an abortive close has occurred.

The public accessors need to be cleaned up so the type is easy to use.

I.e. create the type, add events, call start.

The advantage of this would be less memory fragmentation.

Disadvantages would be areas of the buffer would remain unavailable until the clients callback is called and completed.

Thoughts?

Need to think about the wait times on the various areas and also where the wait are done.

It may be wise to do this within an async{}

Need to investigate, remember to peek inside the blocking queues to checkout whats happening in there.