Socket.Accept delayed by slow connection

Question

5.00/5 (2 votes)

See more:

I have a simple thing which listens on a socket for incoming connections. It binds to the 'listen' socket, BeginAcccepts the socket, calls EndAccept in the handler then immediately re-issues the BeginAccept.

This all works well here in London, and it's happily accepting 20+ short lived connections a second (as part of my stress testing).

Now, I'm getting a computer in Asia (200ms ping) to keep connecting. This works as well, but it holds up the other connections, adding a lag to the acceptance of local sockets.

I am expecting transmission to this computer to be slow and subject to latency, but I can't see why it would hold up other connections being established.

The end effect is that local connections are held up by this long-distance connection creating a local lag.

Any ideas what I can do about this?

Posted 13-Aug-14 2:41am

Rob Philpott

Add a Solution

Comments

Kim Togo 13-Aug-14 9:39am

Calling "EndAcceptTcpClient" takes a long time, before it returns?

Rob Philpott 13-Aug-14 9:48am

Thanks for the response. I'm using socket directly, not TcpClient, so it is just Socket.EndAccept.

I've stuck a stopwatch round the EndAccept, always 0 milliseconds. The delay seems to be not on any particular instruction, but a latency deeper down where accepting takes longer on this connection.

Kim Togo 13-Aug-14 9:54am

If you are using TCP connection, and not UDP, I will suggest to use Wireshark and see what information there is sent and received.
TCP connection has handshakes, window size and other options.

Network Tracing, perhaps? - http://msdn.microsoft.com/en-us/library/vstudio/hyb3xww8(v=vs.110).aspx
My guest is a firewall, not on the computer where the program is. But else where.
Perhaps a Trace route (tracert) can help you see what way IP connection is?

Rob Philpott 14-Aug-14 5:02am

Thanks again. I doubt its a firewall - If I keep the London connections on one port, and the Asia connection on a neighbouring port, this doesn't happen.

Kim Togo 14-Aug-14 5:07am

I always do something like this in my Callback method in BeginAcceptTcpClient.

var tcpClient = tcpListener.EndAcceptTcpClient(ar);

// ServiceEndpoint is a new class, that handles the new tcpClient object and begins with a BeginRead(...)
var serviceEndpoint = new ServiceEndpoint(tcpClient) { TraceLevel = TraceLevel.Verbose };
serviceEndpoint.Start();

// Ready for new connections
tcpListener.BeginAcceptTcpClient(AcceptTcpClientCallBack, tcpListener);

Rob Philpott 14-Aug-14 5:32am

Yes, that's pretty much what I have, although I'm using sockets rather than the Tcp encapsulations - that's because I find they are too eager to raise exceptions.

gggustafson 13-Aug-14 23:23pm

Have you considered using a separate thread for each connection?

Rob Philpott 14-Aug-14 5:03am

I am - once accepted each thread is dispatched off to its own thread. This is just in the acceptance stage which is done asynchronously.

gggustafson 14-Aug-14 8:47am

Are you using the ThreadPool?

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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