C#: Question about socket programming (sync or async)

I'm writing an instant messaging server in C# for learning purposes. My question is whether I should use synchronous or asynchronous sockets to handle the IM clients. The goal is to handle as many clients as possible.

I'm not quite sure but as far as I know with async sockets the packets don't arrive in order which means when you send 2 chat messages and there is a开发者_如何学Go delay/lag it's possible that the second one arrive before the first one. Is this right and if so, is there a way to solve this issue?

About sync sockets: Is synchronous sockets a good solution for many clients? Do I have to check every socket/connection in a loop if there are new packets? If so, isn't this quite slow?

Last question: Assume I want to implement a way to send files (e.g. images) through the protocol (which is a non-standard binary protocol btw), can I still send messages while uploading?

The goal is to handle as many clients as possible.

Async then. It scales a lot better.

I'm not quite sure but as far as I know with async sockets the packets don't arrive in order which means when you send 2 chat messages and there is a delay/lag it's possible that the second one arrive before the first one.

TCP guarantees that everything arrives in order.

Assume I want to implement a way to send files (e.g. images) through the protocol (which is a non-standard binary protocol btw), can I still send messages while uploading

I recommend that you use a separate connection for file transfers. Use the first connection to do a handshake (determine which port to use and specify file name etc). Then use Socket.SendFile on the new socket to transfer the file.

Everything @jgauffin said (i.e. TCP handles packet-order, async better for n(clients) > 1000).

Assume I want to implement a way to send files (e.g. images) through the protocol (which is a non-standard binary protocol btw), can I still send messages while uploading?

Your custom protocol has to be built to support this. If you write a 8MB packet to the Socket, you won't be able to write anything else using that socket until the 8MB are sent. Instead, use upload-chunks of smaller size so that other packets have the chance to go over the pipe as well.

[UPLOAD  id=123 START length=8012389]
[UPLOAD  id=123 PART chunk=1 length=2048 data=...]
[UPLOAD  id=123 PART chunk=2 length=2048 data=...]
[MESSAGE to="foo@example.com" text="Hi"]
[UPLOAD  id=123 PART chunk=3 length=2048 data=...]
// ...
[UPLOAD  id=123 COMPLETE checksum=0xdeadbeef]

The difference between an async approach and a sync approach is more about the difference between non-blocking and blocking io. With both approaches, the data is delivered in the same order that it has been transmitted. However, you don't block while you wait for an async call to complete, so you can start transmitting to all of your clients, before any of the individual communications has finished writing to the socket (which is why typically it would be the approach followed by servers).

If you go down the sync route, you block until each transmission / receive operation has completed, which means you may require need to run multiple threads to handle the clients.

As far as uploading an image at the same time as sending messages, you may want to handle that down a different pipe connection between the client/server so that it doesn't cause a blockage.