January/February 2018 issue of acmqueue

The January/February issue of acmqueue is out now

Kode Vicious


  Download PDF version of this article PDF

ITEM not available


Originally published in Queue vol. 8, no. 8
see this item in the ACM Digital Library


Follow Kode Vicious on Twitter
and Facebook

Have a question for Kode Vicious? E-mail him at [email protected]. If your question appears in his column, we'll send you a rare piece of authentic Queue memorabilia. We edit e-mails for style, length, and clarity.


Jez Humble - Continuous Delivery Sounds Great, but Will It Work Here?
It's not magic, it just requires continuous, daily improvement at all levels.

Nicole Forsgren, Mik Kersten - DevOps Metrics
Your biggest mistake might be collecting the wrong data.

Alvaro Videla - Metaphors We Compute By
Code is a story that explains how to solve a particular problem.

Ivar Jacobson, Ian Spence, Pan-Wei Ng - Is There a Single Method for the Internet of Things?
Essence can keep software development for the IoT from becoming unwieldy.


(newest first)

fool | Wed, 25 Aug 2010 19:02:20 UTC

Use 'netstat' to find out whether you do have lots of connections still in TIME_WAIT or other non-open and non-closed states. (both on client and server)

You could try setting SO_LINGER off on the client's socket. Read up on it (man 7 socket, google, etc.) (There is also SO_REUSEADDR for the server, and there is also a SO_REUSEPORT in some flavor of BSD but this is probably not what you want.) But TIME_WAIT exists for a reason, so if you can change the overall behavior to avoid this deluge of fast short lived connections, that would be better.

You can change the MSS by setting TCP_MAXSEG. Never tried this but based on KV's explanation might do something.

Also remember that you really have no way of knowing whether the other end of a socket has closed their end or just gone away unless you try writing data through it. Otherwise you can just keep reading 0 bytes.

Fran├žois Schiettecatte | Wed, 25 Aug 2010 14:48:45 UTC

I wonder if switching to UDP would be an option to check into, admitedly it does not have the reliability imparted by TCP/IP, but I am more curious if it would get around the ephemeral port limitation. Personally I have found UDP to be very reliable on small networks/controlled environment.

Leave this field empty

Post a Comment:

© 2018 ACM, Inc. All Rights Reserved.