Is this the cause of the slow close and the underlying purpose for it? http://www.freesoft.org/CIE/RFC/1323/24.htm
I believe most systems allow this timer to be adjusted by registry in Windows and /proc in Linux, not sure on Mac If the server does the bind call with SO_REUSEADDR for the listen port it should be able to get back on without waiting for the TIME-WAIT period. http://www.unixguide.net/network/socketfaq/4.11.shtml So those are the parts of the behaviour I would expect to cause a socket busy when there are no listeners. However what you describe seems to be beyond the normal timers. A socket can take a very long time to close if the remote system just crashes and never gets a chance to send a FIN to the peer. I am probably stating the obvious, used to do a lot of network programming about 10 years ago. On Oct 23, 7:54 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > I am teaching a class on Advanced network programming in C?? (nothing > web2py related) and students are reporting to me that Mac OSX takes a > long time to release a port after the program creating the socket has > been killed or crashed. The delay seems to be as large as one minute. > During this time the socket cannot be used again. > > It is a OSX weirdness. > > Massimo > > On Oct 23, 1:52 am, annet <annet.verm...@gmail.com> wrote: > > > Yes, this is on Mac OS X, both Leopard and Leopard Server. I am glad > > it's not just me experiencing these problems. > > > Annet. > >
