What is the right way of doing Client and Server communicate with Sockets in C#?

Question

I've seen many people talk about this any many people have criticised my attempt at doing this and said that I am not following the official rule of "What to send, who sends it, and how the other side responds." Is there even a rule for this? I'm not sure anymore...

Here is my current setup of communication.

• Server: Gets alerted a new client has connected.
• Server: Asks the client for the socket password.
• Client: Sends a packet with the socket password.
• Server: Okay, now give me some information on your device.
• Client: Sends a packet including the device information
• Server: Okay, we've added you to the dictionary, thanks.

Now, if I tell the server to ask the client for the socket password straight away, what if the client hasn't called BeginReceive yet? What do I do about this?

I guess this question is answering my worries of the fact that I'm doing it wrong or I'm doing something wrong, how should I be doing this?

Who goes first? I've been told the client should only communicate with the server and the server should "respond" not "ask". Am I breaking any rules here?

Answer 1

Seegal. Ideally, you'd want to minimize the amount of calls the server is pinging down to the client. The server machine is your powerhouse, and if you're performing intensive work on a potato client PC, you may run into issues. Because you can't just tell people to upgrade their machines to use your service, that's on you.

The method I would use to hand up data would be a packet consisting of bitwise flags that will allow you to package multiple packet cases together without significant issue.

EG

[Flags]
enum NETWORK_CODES
{
    CLIENT_CONNECT = 1 << 0,
    CLIENT_DISCONNECT = 1 << 1,
    CLIENT_PERFORM_ACTION = 1 << 2
}

This way, you can check for multiple flags at once and handle it accordingly.

if(packetFlags = CLIENT_CONNECT & CLIENT_PERFORM_ACTION) then
    Authenticate(packetClient);
    PerformAction();
end //Pseudo; don't hate. :D

It's a scalable solution, which is ideal for networking. If it doesn't scale, then you're in a bad spot and have to redo a whole bunch of code.

The server doesn't need to know if a client is there unless it's an active connection, which cuts back even further the amount of work you actually have to do.

Answer 2

There aren't any universal rules. Design your protocol according to your needs, and then you have rules. A socket is a peer to peer communication system (once the connection is established, in the case of TCP), which means that either peer may send any data at any time. It's purely up to the protocol engineer to design what can be sent, by whom, when, and how.

Think about Secure Sockets. SSL uses a protocol that allows the two peers to send and receive data through a secure channel however they wish, just like the underlying socket allows. On the other hand, think about HTTP. HTTP is purely a request/response oriented protocol. As such, it's far more restrictive than a protocol such as SSL, but it works perfectly well for the use cases it was designed for, along with many more, due to its inherent flexibility at the message level.

To answer the question "who goes first?", you can think of the act of connecting to the server as "going first". You can also think of the act of the server accepting the connection as "going second". So, that puts you back at square one; design your protocol however you see fit. Some protocols involve the server sending some sort of "welcome" message upon accepting the request, and some don't (HTTP, for example); either way is fine. In your case, it might make sense for the server to send a welcome message which contains some flags describing what is required to proceed, such as a password. The client would connect, consume the welcome message, and then proceed as appropriate.

To answer the question regarding whether or not the client has started reading from the socket, it isn't relevant. The server can send data immediately upon accepting the connection; the data will be buffered until the client application reads it by issuing read requests sufficient to consume it.

This is all more open-ended than is really appropriate for SO, but hopefully it helps.