There are always some unexpected things happened in socket
programming.  I implemented both ends of communication and 
performed graceful shutdown and disabled SO_LINGER.
but the port was not released immediately. Somethime it must
waited for half minute before the port was freed.  I guess there
are different layers under tcp socket and any one of them can do
funny things.  Later I didn't care to change SO_LINGER again
because "I guess it is there for a good reason".


Пн, 10 мар 2014, Raul Miller писал(а):
> Agreed...
> 
> Here's one interesting description of some of the issues:
> http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/
> 
> The point of the SO_LINGER parameter is to make sure that the other end of
> the connection has had a chance to receive the data being sent.
> 
> Hypothetically speaking, once an acknowledgement has been received from the
> other side the socket can be shut down even if the SO_LINGER timeout has
> not yet been reached. But software writers often enough misinterpret
> requirements - this happens when people do not make an effort to understand
> *why* the requirement was needed and instead "just code to the
> specification".
> 
> You can't really code to a specification if you don't understand what it
> was supposed to accomplish. Or you can, but the result will be buggy. And
> then once something is deployed people are reluctant to change it because
> that might break other people's work. So there's a sort of creeping
> brittleness that creeps into any computational system, and it can be very
> frustrating to deal with.
> 
> In the case of SO_LINGER you need people who understand the underlying
> internet protocols and their history. Or, you need some impatient people to
> just keep trying and failing until they get it right. Usually we get
> something somewhere in between.
> 
> Or, more succinctly: "I guess it is there for a good reason".
> 
> Thanks,
> 
> -- 
> Raul
> 
> 
> On Mon, Mar 10, 2014 at 10:57 AM, bill lam <[email protected]> wrote:
> 
> > This is socket linger timeout, a feature not a bug. you may set tcp option
> > to disable it but I guess it is there for a good reason.
> > On Mar 10, 2014 10:51 PM, "Pascal Jasmin" <[email protected]> wrote:
> >
> > > actually, an idle loop doesn't always free up resources.  Though load
> > > 'socket' seems to reset it.
> > >
> > >
> > > ----- Original Message -----
> > > From: Pascal Jasmin <[email protected]>
> > > To: "[email protected]" <[email protected]>
> > > Cc:
> > > Sent: Monday, March 10, 2014 10:31:53 AM
> > > Subject: [Jprogramming] sdcleanup_jsocket_ on osx
> > >
> > > sdcleanup_jsocket_ '' on windows will close all sockets correctly.  On
> > > OSX, it seems to require going to idle loop before any reuse of previous
> > > sockets (listen) is done.
> > >
> > > ----------------------------------------------------------------------
> > > For information about J forums see http://www.jsoftware.com/forums.htm
> > > ----------------------------------------------------------------------
> > > For information about J forums see http://www.jsoftware.com/forums.htm
> > >
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
> >
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm

-- 
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to