Introduction

I've been working with sockets since 2000, using Delphi 5.0 and some third-party libraries (Synapse). My very first socket application just copied files between many clients and one server. The client app checks a folder to see if files exist, asks the server where to copy the files in the network and, after copying the files, flags the database record indicating that a file has been moved. The server listens to the client connections, and both exchange XML messages indicating the state of each file copy. Synapse is a blocking socket implementation, and I needed a thread pooling mechanism that works like an HTTP server, because I couldn't keep the connection open (one thread per connection). My solution was to use some IOCP functions to pool the client requests (code) and close the connection after the message exchange was terminated.

Now, using C#, I decided to write a socket server and client library that helps me to only have to think about the message exchange (the process) and let .NET do the hard job. So, I needed the following features:

Asynchronous processing

Some encryption and compression capabilities

Encapsulate the socket, and encrypt the services in the interfaces and separate them from the host implementation

Socket Connection

The ISocketConnection is the base interface for the socket connections, and describes all the connection properties and the methods. The ConnectionID property defines a unique connection ID using a GUID string. The CustomData property defines a custom object that can be associated with the connection. The Header property is the socket service header used in each message that is encapsulated in a packet message. Only messages with a defined header will be accepted. The LocalEndPoint and RemoteEndPoint are the socket IP end points used in the connection. SocketHandle is the socket handle given by the OS.

The IClientSocketConnection and IServerSocketConnection inherit the ISocketConnection, and each one has special functions. The IClientSocketConnection can reconnect to the server using the BeginReconnect method, and the IServerSocketConnection can communicate with other connections in the server host using the BeginSendTo and BeginSendToAll methods, and can get the ConnectionId using the GetConnectionById method. Every connection knows the host, the encryption, the compression type, and can send, receive, and disconnect itself from the other part. This interface is used in the ISocketService interface to allow the user to interact with socket connections.

Internally, in the library implementation, all the connection interfaces are created using the base connection implementations: BaseSocketConnection, ClientSocketConnection, and ServerSocketConnection.

Socket Service

The ISocketService describes the connection events. These events are fired by the host, and have a ConnectionEventArgs argument which has an ISocketConnection that identifies the connection. In the OnReceived and OnSent events, a MessageEventArgs is passed, which has the sent or received array of bytes. In the OnDisconnected event, a DisconnectedEventArgs is passed; the Exception property indicates if the disconnection has been caused by an exception.

The ISocketService implementation can be done in the same host assembly, or another assembly referenced by the host. This allows the user to separate the host implementation from the socket service, helping the administration in a server or a domain.

Connection Host

With the ISocketService created, you need to host the service and the service connections. Both the server and the client host have the same parent class, BaseSocketConnectionHost, which keeps a list of connections, encrypts and compresses the data buffers, enqueues the service requests and ensures that all data buffer has been sent or received, checks messages headers, and checks for idle connections. The CheckTimeoutTimer, periodically, at IdleCheckInterval, checks if the connections become idle, using the IdleTimeOutValue as the idle timeout. Header is the socket service header used by the host. HostType indicates if a host is a server or a client host. SocketBufferSize defines the size of the socket send and receive buffer. SocketService is the instance of ISocketService that drives the message exchange between the connections.

Encrypt and Compress

Every time you send and receive messages, the host checks if the data must be encrypted and/or compressed, and this work is made by the CryptUtils static class. The CreateSymmetricAlgoritm creates an ISymmetricAlgoritm based on the encryptType parameter. The DecryptData and DecryptDataForAuthenticate are used, respectively, to decrypt the received message and check the hash sign on the authenticate procedure. The EncryptData and EncryptDataForAuthenticate, respectively, encrypt the data to be sent and sign the authenticated message.

The encrypted data buffer is labelled with the service header and the data buffer length, becoming a packet buffer. This packet buffer is controlled by the MessageBuffer class that keeps information about the packet buffer offset, length, the remaining bytes, and the raw buffer.

Enqueuing requests

Every time you call BeginReceive or BeginSend in ISocketService, the host checks if some request has been initiated. If a request is in process, the host enqueues the request. If not, it fires the request.

Ensure send and receive

To ensure that all data buffer is sent, the BaseSocketConnectionHost checks the bytes sent, and compares it to the MessageBuffer class. It continues to send the remaining bytes till all the data buffer is sent:

The same approach is used in the receive data buffers because, to read data, a MessageBuffer is used as the read buffer. When the receive callback is called, it continues to read till all the bytes in the message are read:

Check message header

If the socket service uses some header, all the send and receive processes need to create a packet message indicating the header and the message length. This packet label is created using the following structure:

The first label's part is the socket service header. The header is an array of bytes of any length, and you need some advice here: if you choose a very small header, maybe you can have a message with the same array of bytes somewhere, and the host will lose the sequence. If you choose a very long array of bytes, the host can spend the processor's time to verify if the message header is equal to the socket service. The second part is the packet message length. This length is calculated adding the raw message data buffer length, encrypted and/or compressed, plus the header length.

Sending packets

As said before, every time you send messages, the host checks if the data must be encrypted and/or compressed, and, if you choose to use some header, the raw buffer is controlled by the MessageBuffer class. This class is created using the GetPacketMessagestatic method:

Receiving packets

The receive process, if you're using some socket service header, needs to check the header, and continues to read bytes till all the packet message is received. This process is executed in the read callback:

The read callback method first checks if the connection has some header and, if not, just gets the raw buffer and continues. If the connection has some header, the method needs to check the message header against the socket service header. Before doing that, it checks if the packet message length is greater than the connection header length, to ensure that it can parse the total message length. If not, it reads some bytes. After checking the header, the method parses the message length, and checks with the packet length. If the length is equal, it gets the raw buffer and terminates the loop. If the message length is less than that of the packet message, we have the message plus some data. So, the method gets the raw buffer and continues to read using the same MessageBuffer class. If the length of the message is greater than that of the packet message, before reading some data, it just resizes the packet buffer to the message size, ensuring enough room for more read bytes.

Checking idle connections

Using the BeginSend and BeginReceive methods of ISocketConnection doesn't return some IAsyncResult to know if the method was completed or not allowing disconnection after some timeout value. To prevent this, the BaseSocketConnectionHost has a System.Threading.Timer that periodically checks the LastAction property of BaseSocketConnection. If LastAction is greater than the idle timeout, the connection is closed.

Crypto Service

The ICryptoService describes the authentication methods fired when the connection is made to the other part. The OnSymmetricAuthenticate method is fired when EncryptType.etRijndael or EncryptType.etTripleDES is used, and OnSSLXXXXAuthentication is fired when EncryptType.etSSL is used. Like ISocketService, the ICryptService can be done in the same host assembly, or another assembly referenced by the host, so you can have one ICryptoService implementation used in many ISocketService implementations.

SSL authentication

There's a new stream class called SslStream in .NET 2.0 which can authenticate SSL streams. The SslStream's constructor accepts a NetworkStream class, and this stream is created using the Socket class. So, using SslStream, you can send and receive data buffers using socket connections.

Server authentication

The SslStream authentication is done in both the client and the server, but each one has different parameters. In the server side, you need to pass a certificate using the X509Certificate2 class, either finding in the certificate store using X509Store, or by creating it from a certification file (.cer). Also, you can request a client authentication and check the certificate's revocation. The following code is an example of an SSL server authentication using ICryptService:

Client authentication

On the client side of the SSL authentication, you need to pass the host name of the server certificate, and if this name doesn't match, the authentication fails. You can pass a client certificate collection using X509Certificate2Collection. If the server doesn't request a client authentication, you don't need to pass the collection but, if the server requests it, you can find the certificates using X509Store. You can also request a client certificate's revocation. This is an example of SSL client authentication in ICryptoService:

Certificates

To create certificates, you can use the MakeCert.exe tool found in .NET, and there's a lot of information available about it. You can take a look at John Howard's page, this MS post, and this website.

Symmetric authentication

To implement some symmetric encryption and authentication in this library, I decided to put a post in Microsoft newsgroups. Unfortunately, for the post, but luckily for the knowledge sharing (many thanks to Joe Kaplan, Dominick Baier, and Valery Pryamikov), I decided to use William Stacey's implementation example "A generic method to send secure messages using an exchanged session key". In this code, the symmetric key used in the session is encrypted and signed using RSA key pairs, and the client part needs to know the encrypted server's public key, meaning that this key isn't received from the server in the authentication process. Both the client and the server need to know this key through a manual process. To ensure this, the OnSymmetricAuthenticate needs a RSACryptoServiceProvider class providing the key pair for encryption. You can fill the RSACryptoServiceProvider from an XML string, a file, a CspParameters class, or a certificate. Here is an example of symmetric authentication:

The authentication message

The symmetric authentication uses the AuthMessage structure to exchange session keys between the client and the server. The SessionKey and SessionIV properties are, respectively, the symmetric key and the initialization vector of the algorithm. The Sign property is the hash code generated by the client using the sign RSACryptoServiceProvider class created internally, and its public key is exchanged using the SourceKey property. This internal sign key pair is necessary to sign the AuthMessage, and the server can ensure that the AuthMessage is accurate. This process is done using the following code:

On the client side of the symmetric authentication, the OnSymmetricAuthenticate is called, getting the RSACryptoServiceProvider to encrypt the session key generated by the CryptUtils.CreateSymmetricAlgoritm method. The AuthMessage is filled with the encrypted session key, session IV, and the sign public key. To sign the message, the SourceKey, SessionKey, and signMessage are used, and the resulting hash is assigned to the Sign property.

On the server side of the symmetric authentication, a MessageBuffer is used to receive the socket buffer. The read callback method continues to read till a completed AuthMessage is received. With this message, the method calls the OnSymmetricAuthenticate to get the RSACryptoServiceProvider to decrypt the session key, session IV, and the sign public key. With all the keys decrypted, the method verifies the Sign property to ensure that the AuthMessage is accurate, using the SourceKey, SessionKey, and signMessage.

Connection Creator

Although BaseSocketConnectionHost can manage ISocketConnection connections, it cannot create them. This job is made by BaseSocketConnectionCreator which creates and initializes ISocketConnections. The CompressionType and EncryptType properties define, respectively, the compression and the encryption types that will be used in the connection. The CryptoService defines the ICrytoService instance used to initialize the connection, if needed. The Host property defines the host of the BaseSocketConnectionCreator; it can be a server or a client host. The LocalEndPoint defines the socket IP end point used in the connection, and it can have different behavior depending on the type of the creator.

SocketServer and SocketListener

The SocketServer and SocketListener are the classes needed to create a socket server. SocketServer is derived from BaseSocketConnectionHost, and manages ISocketConnections. The SocketListener is derived from BaseSocketConnectionCreator, and listens for incoming connections, accepts a connection, and creates a new ISocketConnection to be used. A SocketServer can have as many SocketListeners attached as required, each one assigned to a local port to listen.

SocketServer constructor and methods

In the SocketServer constructor, the socketService parameter defines the ISocketService instance used by the server. The header parameters define the array of bytes used in the message header exchange. The socketBufferSize adjusts the socket buffer size. The messageBufferSize defines the maximum message size of the service. The idleCheckInterval indicates the interval for idle connections checking, in milliseconds. The idleTimeoutValue defines the timeout, in milliseconds, to be compared to each connection LastAction property.

To add SocketListener items in SocketServer, the method AddListener must be used. The localEndPoint parameter defines the local socket IP endpoint used to listen to connections. The encryptType and compressionType defines, respectively, the encryption and compression methods used in the new accepted connection. The cryptoService defines the ICryptoService used to authenticate the encryption method chosen. The backLog limits the listen queue of the OS socket to the defined number, and acceptThreads sets the calling number of the socket's BeginAccept to increase the accepted performance.

HostThreadPool

This library uses asynchronous socket communication which, in turn, uses the .NET ThreadPool. In the .NET 2.0 ThreadPool, the thread number can be controlled using the SetMaxThreads and SetMinThreads methods, and I think there are a lot of improvements in this class. But, if you don't want to use the .NET class, you can use a managed thread pool called HostThreadPool, very similar to Stephen Toub's ManagedThreadPool. HostThreadPool uses a list of managed threads that keeps increasing as more enqueueing tasks are provided. To use this class instead of the .NET ThreadPool in SocketServer, just set the minThreads and maxThreads constructor parameters to non-zero numbers.

SocketClient and SocketConnector

The SocketClient and SocketConnector are the classes needed to create a socket client. SocketClient is derived from BaseSocketConnectionHost and, like SocketServer, manages ISocketConnections. The SocketConnector is derived from BaseSocketConnectionCreator, and it connects with the socket server and creates a new ISocketConnection to be used. A SocketClient can have as many SocketConnectors attached as required, each one connecting to a socket server, and they can be assigned to a local address and a local port to start the connection.

SocketClient constructor and methods

The SocketClient constructor has the same parameter signature as the SocketServer class. To add SocketConnector items in SocketClient, the method AddConnector must be used. The remoteEndPoint parameter defines the remote socket IP endpoint used for the connection. The encryptType and compressionType define, respectively, the encryption and compression methods used in the new connection. The cryptoService defines the ICryptoService used to authenticate the encrypted method chosen. The reconnectAttempts and reconnectAttemptInterval define, respectively, the number of reconnect attempts when using BeginReconnect method and the time interval to reconnect. The localEndPoint defines the local socket IP endpoint used to start the connection process to the remote endpoint.

Echo demo project

There's an Echo demo project available in the article download file, using Console, Windows Forms, and Windows Service hosts and clients, and all them use the same EchoSocketService and EchoCryptService. The demos are divided by their type as follows:

Hosts

Console

EchoConsoleClient

EchoConsoleServer

Windows Forms

EchoFormClient

EchoFormServer

Echo<code>Form </code />(Forms template)

Windows Service

EchoWindowsServiceServer

Services

EchoSocketService

EchoCryptService

Conclusion

There's a lot going on here, and I think this library can help anyone who wants to write asynchronous sockets with encryption and compression. Any comments will be appreciated.

History

May 15, 2006: Initial version

May 19, 2006: Some English text corrections (sorry, I'm still learning!), and rechecking the demo sources

June 06, 2006: Version 1.2 with the following changes:

Minor bugs fixed

All "Sended" changed to "Sent" (thanks vmihalj)

ReadCanEnqueue now works correctly and with HostThreadPool (thanks PunCha)

Added reconnectAttempts and reconnectAttemptInterval to allow client connection reconnects as many times as is needed in a timed interval (thanks Tobias Hertkorn)

April 01, 2007: Version 1.3 with the following changes:

Fixed rawbuffer = null

Fixed BeginAcceptCallback: stops accepting if exception occurs

Fixed BeginSendCallback: PacketRemaining bytes should be used

Socket config section added in demos

New message size (64K)

HosThreadPool removed

Header changed to Delimiter property with new delimiter options:

dtNone: No message delimiter

dtPacketHeader: Version 1.2 backward

dtMessageTailExcludeOnReceive: Use custom delimiter at end of message (Exclude delimiter on receiving)

dtMessageTailIncludeOnReceive: Use custom delimiter at end of message (Include delimiter on receiving)

Exception System.Security.Cryptography.CryptographicException: Object identifier (OID) is unknown.
-
Worked well under testing environment. However, this is the error I got when I put it on to a windows 2003 x64 server.
Is there a fix to it? Anyone happen to know how? Please help!!!

great work by you~
i got a problem running the demo chatclient and chatserver,it seemed that when i runned the server and client on the same computer,the server couldn't hold a connection for the fifth client !i mean the connection won't last long ,it disconnected the moment it connected the server,i didn't event had a chance to send message.but the preceded four connections worked well,i don't why.

So obviously, the problem is that the MessageBufferSize in both the server and client are too small at 512 bytes. The message buffer includes a list of the connected users (to display in the user list panel of the client) in some instances, so once you include a 5th user, the buffer size requires more than 512 bytes.

You can fix this by increasing the MessageBufferSize in both the client and server. In my tests, setting it to 1024 allowed me to connect over 20 clients without issues. Note though that as the number of users and/or length of nicknames increases, the size requirement will increase.

Does anybody know how to create client certificate for client authetication?
I tried many times but always got an AuthenticationException: The remote certificate is invalid according to the validation procedure.

Im using Windows 7 / C# express 2008.
1. I start the server.
2. Start the cliente ( connection is ok ).
3. If i stop the cliente, its freeze and on debugging, i can see it stops at that line...

It occurs also with echo demo. Other demos i dont have tested.
Im trying to write a very simple client/server to manage my lanhouse. Until now, i have used the RakNetDotNet, but i need to use sothing smaller and more simple.
I need to exchange no more than 15 litle messagens with server, almost all is a word like "CloseProgram","Minimize", "Restore", or "StartTime;30:00;aUsername".
The most complex is a screenshot.
Im from Brasil (RS).

In an earlier version of the library, the header was removed to have a delimiter. I actually modified it to have a header system instead and it wasn't any more stable in terms of sending messages. The delimiter works just as well as the header, so there shouldn't be a problem for your use.

Both the delimiter and header would be fine for sending files. The idea behind both is to cut the file into chunks, send that chunk, make sure the chunk is correct and repeat. There should be some segmented file sending projects on here that you could get the idea from and then use this library for.

Can you post an example about Asynchronous Socket (using UDP socket)?
I need a high performance UDP server.
I read the sample at http://www.codeproject.com/KB/IP/ChatAppAsynchUDPSocks.aspx, but it has bad performance.

Hi
with a bit late, I guess you have to change the socket type and the protocol type in the SocketConnector and SocketListener class
Replace
FSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
by
FSocket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);

Very neat code.
I have created a service which includes this project. In my project, there are currently about 250 GPRS based TCP clients connected. Each client sends a very short 4 byte TCP payload to prevent the cellular PPP connection from closing. These KeepAlive messages are acknowledged by the server. I set the FIdleTimeOutValue so that the CheckSocketConnections() will disconnect a socket that is idle for 10 minutes which is way over the cellular PPP closure time.

Could it be that one of the CheckSocketConnections() function's BaseSocketConnection items has already been closed when the cnn.BeginDisconnect(); is called?

Do you have any ideas on how to track down this problem that randomly happens over a couple of days in a release version?

Where should I look?
The service may be hosted on a dual or quad core PC.
Is there any place I may be should add a try catch sequence?
Since this is a Cellular end unit project every time that the server restarts costs more data as GPRS PPP must reconnect and the providers' charge for all data transferred.

2) Packed Keep Alive in incoming messages
Sometimes the short incoming 4 byte KeepAlive messages are received packed in groups of 2 or 3.
I have set Nagle to off in the server.
Is there any reason you can think of that the sever would accumulate tiny TCP packets?
I guess the problem is on the cellular GPRS end units or in the cellular provider's backend but since I am writing I thought to ask.

Thank you very much for this library. I have been writing a chat program using it and it has performed wondefully. There is one error that has kept on popping up throughout my development though. Sometimes I will get an IndexOutOfRange exception when the client receives a message from the server. This seems to happen most often when I am sending several packets at once to one client but it also happens randomly when receiving messages. Sending one packet to several clients works just fine but sending several packets to one client always breaks it. I have since changed my code so there are no bursts of packets like that but having the thread sleep for at least 300 ms always kept it from crashing.

Both the client and the server are inheriting from BaseSocketService. Changing the client to use SocketClientSync resulted in the same error.

I have been having trouble like this frequently and spent a few days last week tracking it down. The problem was mostly in the routine ReadMessageWithTail that extracts messages from the receive buffers. The reason it shows up when sending several packets at once, is that the first packet always (?) goes in a single socket-level buffer, but that messages sent 'quickly' may be packed into multiple socket-level buffers and even span buffers. The code that looked for delimiters and extracts the messages from these buffers is broken.

Here are the fixes I made, the comments are very helpful I think:

BaseSocketConnectionHost.cs:

#region ReadFromConnection

/// <summary>
/// receive bytes transmitted by BeginSend(). The buffer may contain a single message, or multiple
/// messages, and the end of the buffer may contain the first part of a message to be continued in
/// the next buffer to be received.
/// </summary>
/// <param name="connection"></param>
/// <param name="readBytes"></param>
private void ReadFromConnection(BaseSocketConnection connection, int readBytes)
{

// readBytes is the actual number of bytes read from the Socket into the buffer

// if a partial message was received previously and shifted to the beginning of the buffer, e.Offset
// would have been adjusted to point to the byte following that partial message. processBytes is
// the total length of buffered data assuming a starting offset of zero.

int processBytes = readBytes + e.Offset;

// call FireOnReceived() for each complete message contained in the buffer

// remainingBytes is the number of bytes at the end of the current buffer, to use with the next buffer
// to rebuild the message. Reallocate the socket buffer large enough to hold this unprocessed data
// PLUS the next incoming buffer. e.Count ensures that the next buffer will be stored immediately
// following the unprocessed data from the current buffer.

if (!onePacketFound)
{
// no message delimiter was found in the buffer - as in the case dtNone
// is it possible for a delimited message to span multiple buffers??? if so, this code probably won't work

// SetBuffer():
// The offset and count parameters can't be negative numbers.
// The combination of the offset and count parameters must be in bounds of the buffer array in the Buffer property.
// This method sets the Count property to the count parameter and the Offset property to the offset parameter.

}
else
{
// a partial message remains in the buffer, to be continued in the next buffer
// save this message fragment to process together with the next buffer
// maximum size for one complete message is FMessageBufferSize
// messages span at most two buffers - start in the first buffer, are completed in the second

// it seems to occur if large messages are sent "fast" due to the buffering algorithm
// on the sending side.

// by catching this exception, the previous behaviour (trapping immediately OUT of this function
// and terminating the read) is prevented - since the value in e.Offset will prevent proper handling
// of future messages, probably the connection should be Disconnected at this point!
try
{
// copy remainder of message to the side buffer
// e.Offset points to the next unprocessed data byte
// remainingBytes is the number of unprocessed data bytes
Buffer.BlockCopy(e.Buffer, e.Offset, readMessage, 0, remainingBytes);

// point the socket buffer to the new buffer containing the beginning of a message
// so that the next socket buffer will be appended to it

// ====================================================================================
// this is where the next Socket read is requested
// ====================================================================================

/// <summary>
/// extracts one or more messages from a buffer, and calls FireOnReceived() for each complete message found.
/// Partial messages are left for the next buffer received from the Socket
/// </summary>
/// <param name="connection"></param>
/// <param name="e">current descriptor and data buffer, containing one or more messages separated by delimiters</param>
/// <param name="dataBytes">number of valid data bytes in e.Buffer, beginning at offset=0</param>
/// <param name="MessageFound">output: TRUE if the at least one complete packet was completed and FireOnReceived() called.
/// If the return value is zero, it means there were no message completions found - otherwise it means that some of the bytes
/// at the end of the buffer are part of a future message and should be saved for next time. </param>
/// <returns>number of data bytes unprocessed in e.Buffer - which should be saved and prepended to the next data buffer.
/// If greater than zero, e.Offset points to the next unprocessed byte.</returns>
private int ReadMessageWithTail(BaseSocketConnection connection, SocketAsyncEventArgs e, int dataBytes, ref bool MessageFound)
{
// default return values

while ((messageOffset < dataBytes) && (delimiterOffset >= 0))
{
// find all the messages in the buffer
// each series of message bytes is followed by the message delimeter
// if there is no delimiter following the last message identified, the unprocessed bytes are part of the next message in a future buffer

// match remaining characters of delimiter
// if the complete delimiter is not found here, it may occur later in the buffer
// so keep scanning until the entire buffer has been examined
// the entire delimiter must be contained in the buffer and not span to the next one !!

Thanks a lot for the code! It looks like it should work just fine but when I plug it into the three regions and run my program again OnReceived is not firing. It does detect the connection to the server. Were these changes made using the 1.5 or 2.0 version and did you make any other changes as to how the received messages are handled? I am currently using the latest version with a class based off of the SocketServer in the chat example.

This library does work, and I have extended it for my project in various ways. The chat server is the best model for my use. However I have had to fix this bug and others at the chat-server level, and another one or two mentioned already in this forum at a lower level, to make it more bullet-proof. No doubt there are a few more bugs lurking ... however the load tester I wrote sends many thousands of messages at full rate to a dozen or so clients, at a very good clip. You can't say the same about the EchoTester load tester provided with the project. Too bad the "ChatSocketMessage" encoding makes the minimum message transfer size something around 600 bytes, but I will address that too as my project goes along.

I will play around with it later, from your other replies it looks like you know what you're doing so I'm going to try and use the other modifications you have made and see if that fixes things. If all else fails I'll ask the creator for the modified files he gave the other people. This is definitely an excellent TCP library and I'll be using it a lot for other applications once my current job is finished.

Right now in my program I am using extended versions of the ChatMessage and MessageType class/struct that were in the original chat program just for easiness. I have UDP data going back and forth where I create each packet byte by byte so if size is a concern I would definitely recommend doing it that way. I wouldn't say it's needed for a TCP connection but I'm not worrying about optimization right now either.

Then it will find the next delimiter instead of searching for the same delimiter position over and over again. Now it works perfectly. Thanks a lot for the code!

edit: Actually, while regular messages work, when there is a message spanning multiple buffers it goes into an infinite loop like before. I will work on fixing it.

edit again: Well, it looks like it's actually a problem with a voice chat component I had been developing, not the library. However, using the method I described above it will still throw errors when reaching the end of the buffer. Instead of adding one in the find method, at the end of the while loop I put delimiterOffset++ instead, which will cause the buffer to be returned to the ReadFromConnection method instead of trying to search for something out of the range of the buffer.

hello mikey222 i m having same issue and i have implemented your code as it as but now i cant even connect to server i dont face exception but i am sticking at ReadMessageWithTail (for loop) and this for loop starts a never ending scenerio

"I faced the same problem and it seems that I found solution. In my project
exception IndexOutOfRangeException occured at: BaseSocketConnectionHost/ReadFromConnection..."

The way to solve the problem I described in that message was wrong and
I still received exceptions on my attempts to deserialize received objects.
I had to spend a couple of days to understand the code, make changes
and now I have new versions of files <basesocketconnectionhost.cs> and
<bufferutils.cs> that receive and parse binary data without exceptions.
I could share these versions of files with other developers, so I need
to know what is the better way to do it.