Re: Sockets and the RI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



David Daney wrote:
> Robert Schuster wrote:
>> Hi,
>> I still have trouble with the Sockets ....
>>
>> First I found out that certain Sockets which do not succeed in
>> establishing a
>> connection (a wanted scenario in the mauve test) do not get properly
>> closed. I
>> took some time until I found the simple answer: These sockets do their
>> connect()
>> attempt inside the constructor. When connect() throws an exception the
>> caller
>> will not get an instance on which it can call close(). I therefore
>> added some
>> exception handling code and thought: "Yeah, now those spurious
>> BindExceptions in
>> every quick second test run will be fixed."
>>
>> However this is not the case. :(
>>
>> A little googling about 'unbinding' a socket revealed that this is
>> achieved by
>> closing it (fine I thought). However it also tells that a closed
>> socket remains
>> busy for 60 seconds on most systems. Ok this looks exactly like the
>> problem I faced.
>>
>>   
> 
>> But WTF? Running the tests quickly after on the RI does not cause those
>> BindExceptions? What is this? Magic?
>>
>> I felt lost and so put out strace to see what the RI is doing with my
>> operating
>> system. I saw no special system calls and to my surprise not a single
>> failing
>> bind() call.
>>
>>   
> 
> Do they set SO_REUSEADDR? on the listening socket?  That is the only way
> I know of to be able to bind to the same address before the timeout
> expires.
> 
> Also if there is a clean shutdown of any TCP connections that took place
> on the socket that would help the situation.  Are you calling shutdown()
> before closing?
> 

I second David here. Explicit shutdown must be used before closing
connection. "close" only unbind a filedescriptor to the target channel
(TCP/UDP/anything). "shutdown" closes the connection. It happens that
"close" also shutdown the connection generally because you are the
latest bound to the target channel. However it may happen where this
expected behavior gives unexpected results on the other side of the
connection.

Cheers,

Guilhem.


[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux