Click here to Skip to main content
15,036,823 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
See more:
Hi all,
just thought id ask you guys for your thoughts on something i'm looking into doing.

Basically looking to develop a Server that will accept TCP connections. The clients will not be connected constantly, i.e the clients open connection, send data to the server, the server will send back ack, nak or some data and then the client closes.

The amount of clients the server will have to service will be around 1000-2000, but i would like the confidence of knowing it would work with more :-).

The connections from the clients will be totally random with regards to time thus, in theory there is a possibility that the server could get hit with 100s of requests at any instance in time.

So my question is what do you guys think the best route to take is for the server side sockets is ? Async ? Sync ?

Also another thing i should mention is the data the server receives will need to be pushed into a SQL database.

Look forward to any comments you have :-)
Lee Trueman 7-Dec-11 11:47am
now i'm really confused as i there are alots of articles on here that say for performance async is the way to go.

I would not have thought spawning of a new thread per connection was very efficient, especially if the server got hit with 100s of connections at the same time ?

1 solution

I think everyone should prefer synchronous API relying on your threads instead. For example, a network service typically need just tow thread to work with sockets, let me call them "listening thread" and "application protocol thread". Usually the best TCP API is TcpListener/TcpClient. The listening thread is listening for new connections, accepts them and put obtained client sockets (objects representing connected remote sockets on the service host) and put it in some collection shared between threads. The application protocol thread is reading/writing from/to network stream to follow some application-level protocol. A disconnection from either side could be processed to remove an item from the collection, so no graceful disconnection is needed. Of course you need to use appropriate thread synchronization primitives.

Same way, the client part needs a separate thread to work with sockets, just one.

See also my past solution: using api in c# and socketprogramming[^].

Franky, I don't know situation where asynchronous APIs could be preferred over custom threads. Threads are easier to program and provide more explicit and fine-grain control. I think asynchronous APIs were offered to developers when threading was not a common place as it is now and now is only useful to support legacy code. No need to use it for new development.

Espen Harlinn 5-Dec-11 17:44pm
Good reply as usual :)
Thank you, Espen.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900