We Keep Coding

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

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?

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.
E.G.
[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.

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.

Async Sockets in C# - Knowing your clients

I'm sure this has a simple work around, but right now I seem to have the inability to find an elegant solution. I have built an ASync C# server application which accepts multiple clients and handles them well, but to proceed I need to be able to determine which clients are connected to my server (there will be only two clients both of which do different things).
When my program accepts these clients I want the server to know the clients address and an indication which client is which potentially stored in a small list.
So I guess what I'm asking, is there a simple means of when the client has connected, sending a predefined message to the server letting it know what client application goes to which address?
Thanks

There are numerous ways.
One of the easiest is to have a different port for each of the client applications. The other way is in order to "connect" (after TCP Handshake) is to send a message identifying the application before any data is exchanged. The other option would be to add headers to each requests / reply stating the application and storing that.

You are free to send all kind of data over sockets.
To solve this, invent some kind of protocol between client and server.
For instance sending a first message when connecting to identify the client to the server.
From there on continue with the normal conversation between those two.
Server can accept the message and store of show it, or even reject the client when the first message does not contain the agreed information.

Simple Network Programming in C# for Beginners?

I am currently new to C# and I need to understand simple server-client architecture!
I am currently trying to write a simple server/client program where basically a client can send a variable to a server and the server can send it to another client. Problem is that I am really blind to this as I am still very new to C# although I have some experience with Java (But still not with networking).
My question is:
How many files will i Have to write?
Can anybody be nice enough to provide me with a framework or example for a program like this?
What is a TCP server?
This is intended to be for an online game. One client will roll the dice and the server must show all the other clients that this is the value the first client rolled.
Any help would be greatly appreciated!

Answer to all of your questions: MSDN - Network Programming (.NET 4)

Since you are planning on TCP (because you want state) you need to develop a strategy. You'll get plenty of information about establishing a connection and moving some sort of data back and forth. Google will give you more than you can handle. Without doing all the work, here are a few steps to get you oriented.
1) Connection Registration - When a client comes online and wants to communicate with the server it first needs to say "Hey I'm here and want to role some dice." This initial handshake could be a connection id that is used for a heart beat and/or transactions. The server will use this to identify data and the respective thread if open.
2) Heart Beat - Now that the client has registered with the server the client is responsible for providing a heart beat saying it's still there and still planning to continue work. Typically every 3 - 10 seconds is good.
3) Develop the Request/Response protocol - For "every command" there will be a formal process. This formal process will include the connection id but also a request id. The client will not accept a response unless it receives the corresponding request id. Furthermore, every request will require a success or fail response to identify if it conforms to the API or what not. Within the request will be the command or action to perform. Some people use int's to dispatch a command id then use a switch on the id to call an entry-point method (cmd id = 1 is connect(), cmd id = 2 is rolldice(), etc). You might include additional payload that identifies the result from the command.
In short, 1 is the handshake, 2 is the keep-alive and 3 is passing data back and forth.
Now whether to use socket or WCF, I'd recommend to have a basic understanding of TcpClient programming then run with WCF. You'll be amazed how simple socket programming is but the overhead is a killer. Nothing to be intimidated by. It's a lot of work to coordinate calls, threads and not to mention security. WCF on the other hand does shave some of this overhead off.
I'd check out this question...
How to use socket based client with WCF (net.tcp) service?

1) The number of files will depend on your particular implementation. You can create this architecture as simply as 1 class for the server and 1 class for the client (you can have more than one class in a file). Depending on the complexity and choices you make during the design you could have many files or just a few.
2) A good tutorial for a simple TCP server / client can be found here
3) A TCP server is a process that waits for a connection from a TCP client. TCP stands for Transmission Control Protocol. From Wikipedia: TCP provides reliable, ordered delivery of a stream of bytes from a program on one computer to another program on another computer.

How to connect a Chat Client to a game server?

I just want to create a "Chat Client" that can connect to a Game Server..
My problem is that I dont know how to start, I've already read several tutorials about socket programming / chat client / server client / etc. but I can't find a way to implement it on a game server.
The server I want to connect is a Battle.net server "Warcraft III".
I've already know the IP Adress of the server but I dont know how will I able to access the game server.
The IP address of the server serves as a Webserver "acts a forum" and a GameServer "of course the game itself".
to summarize my problem:
I just want to create my own "Topaz Chat" using C# but I dont have any idea how to do it?
any idea? guys even a keyword is enough, I will try my best to find a tutorial for it. I know its hard to answer my question because I failed to provide any code T_T

First things first, you need to find out the protocol that the chat uses. Try to find answers to these questions:
Do you really need raw sockets?
Is the protocol a know protocol, such as IRC?
What are the chat's commands and how are they processed?
When you find these answers, you'll be half way there.

If you are saying that you can access the Battle.net to get some informations, then I believe it uses a WEB SERVICE. Using it, you can request some informations or to create a room or something. You should not use socket programming. WCF is a highter level technology of .NET. Use it as web service.

Re-Implement 3rd party TCP Java client

I need to know if there are any tools to figure out the interface to a TCP client. My Company has purchased a 3rd party tool and we really like the Server side and most of the client side.
I would like to see if I can figure out the calls that the client side makes to the server so I can create the client side functionality we want.
I have been able to figure out what the port number and protocol that the client communicates with the server on. Since we host the server, I have full access to that too.
Any ideas on how to get hold of and execute the methods that the client app is calling on the server?
I am not that good at java, so I would like to use C#.NET if at all possible. Does that sound feasible?
NOTE: I have done something like this before (connect to a 3rd party Java Based Server with a custom .NET client) but that time I had a bit of documentation to get me started. This time I have nothing.
Any Help will be greatly appreciated.
Also, if you know better tags for this please post them as comments (or just re-tag if you have the permissions)

If you're trying to reverse engineer the protocol so you can write your own client to the server, get Wireshark. You can use it to follow the conversation between client and server.

You could attempt to decompile the library. That should give you all of the low-level info that you need.

You could also use TCPMon to grab the exact message text passed between client and server.