[Tutor] TCP server/client application failing. Need some help with the basics!

Alan Gauld alan.gauld at btinternet.com
Tue May 12 01:49:58 CEST 2015


On 11/05/15 21:07, Anubhav Yadav wrote:

> I wanted to write a simple TCP client/server (where in the server acts as a
> simple TCP Listener). I searched on the forums and I saw that people
> advised using frameworks like twisted and sync.io for client server
> applications to take advantage of asynchronous model.

Yes, for large scale work I'd second that recommendation.,
But when learning its often better to start small.

> multithreaded model, so I decided to start by implementing a multithreaded
> server, and then improve as I go on facing issues.

But starting with a multi threaded server is not what I'd
call starting small. Its quite advanced. I'd start getting
non multi threaded servers running reliably first. Then
I'd try adding some threading. As in maybe a dozen
connections sharing some data source..

Only then would I even consider the extra issues of
scalability to thousands of connections...

> Is it even right to create many thousands clients using threads on the same
> machine?

It may be theoretically possible but when I was designing
large client server/web based systems I used a rule of thumb
that said not more than 100 connections per core. So for 5000 
connections I'd need 50 cores. Allowing one core for the OS to
run per box that leaves 7 cores per 8-core server, so I need
8 servers to handle 5000 connections. For resilience I'd
add another one (so called N+1 architecture).

Now those servers were all carrying significant processing
requests not simple ping-like requests, so on that basis I'd
guess that you don't need 50 cores for your example. But
it does seem like a lot to ask of a single box. And if you
intend to extend that to a network model think about the
load on your network card too. My servers at work all
had a couple of (gigabit) network cards connected.

> Would love to understand the details of threading and sockets! Please do
> leave your comments and criticize me. Sorry for this long post.

Too much code for me to read at this time of night, but I
would try slimming down your testing, at least initially.
Make sure it works on lower loads then ramp up slowly
until it breaks.

The other thing I'd consider is the timing of your requests.
I didn't check but have you a decent gap between requests
or are all 5000 arriving nearly simultaneously? It may
be a network configuration issue - the socket/port queue
simply getting choked to the point where packets time out.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos




More information about the Tutor mailing list