views:

85

answers:

4

I'm using c# to design a client-server application. I'm still a beginner, and am learning the ropes of c# and OO. Right now, I wrote on a piece of paper a few ideas. Essentially, I would create a class "client", which contains all the details (sockets, etc). The client class would be created and stored in an array which would be used by the server in a loop. If 100 clients are connected, would the memory used be significant?

I guess the server would loop through every client in the array checking for a "dataSend" flag that would then flag the server to create a NetworkStream object to the client.

Should I create a networkstream object upon connection of the client and close on connection?

If anyone could point me in the direction of writing my own client-server software, it would be appreciated.

+1  A: 

An array of client classes representing each client connected to the server is a good way to handle this. You might also want to have a member class representing the actual socket and network code, its keeps it cleaner.

Pro tip: Check out the source code to some MUDs.

tm1rbrt
What do you mean by member class?
cam
You would have a client class (in the server source code) that represents 1 client connected to the server. Then you would wrap up all the code to communicate with the client into another class (for example 'networkInterface') which would be a member of client class. That way all the logic to handle client data and the code to communicate with the client is kept seperate.
tm1rbrt
+1  A: 

Cam, we need a bit more detail about what you are trying to achieve to give you a really good answer. Generally, I'd suggest you make use of WCF. You simply need to create a service, define an interface for your operations, and then as many clients can consume that interface as you wish. It's pretty easy in practice.

CraigS
+1  A: 

Cam, what you've described isn't quite real client/server design, as the two sides are tightly coupled in your scenario, sharing an array of objects. Think about it instead in terms of requests and responses. The client makes a request to the server over the network, and the server returns a response over the network to the client. They share two things: a common network connection and knowledge of the interface that the server exposes.

The Web is a great, familiar instance of this pattern. The client, your browser, composes an HTTP Request and sends it over a network connection to the server. The server interprets the request and sends an HTTP response back to client. Each knows how to interpret the HTTP standard. That is the link between them, nothing else.

I'd suggest starting out with implementing a very simple request/response. For instance, the client sends a request of 'TIME' and the server responds back with the current time, and the request 'DATE' responds back with the current date. By having a simple protocol to implement, you can concentrate on learning the mechanics of .NET's networking classes.

Adam Crossland
+1  A: 

Something like this would be appropriate:

  • Like you said, a class Named client to hold client socket.
  • Maintain a table on server with client's ip:port as key, and client object as value. This will help you keep track of connected clients.
  • Use asynchronous send and receive for clients. So rather then you iterating through clients, every client will receive data, do the job and respond back to the connected client.
cornerback84