[PATCH] jdk1.4.2, getsockname(), and ECONNRESET

[Landon Fuller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jun 21, 2005, at 14:01, Greg Lewis wrote:

> Hi Landon,
>
> On Linux and/or Solaris, what happens when you call getsockname() on a
> socket that has had the connection reset by the peer?  In particular,
> is it compatible with what your patch does or are we introducing a new
> scenario that the socket code for applications must handle?

I looked over the Linux network implementation to be certain. When the 
socket is reset, the source address and port are reset to 0. The kernel 
handles IPv6 vs. IPv4 sockets, returning the correct sockaddr type.

In our case, we're only provided with the file descriptor, leaving us 
with no means to discern whether the socket was formerly connected via 
IPv4 or IPv6 - as such, we're forced to improvise by returning a 
sockaddr_in if an error occurs. In terms of the localPort() method, 
this makes no difference to the calling Java code as only the port 
number is returned.

In the localAddress() method, returning an IPv4 address should not be 
fatal. For localAddress() to in turn call getsockname(), the connect() 
must have been issued without a bind() first being issued (otherwise, 
java would have cached the local port and address previously). There 
should be no expectation by the caller that either a Inet4Address or a 
Inet6Address will be returned.

It would obviously be more correct to pass up the 
java.net.SocketException (as opposed to the current java.lang.Error), 
but our hands are tied by the published API.

>> Also, any comments on the thread-safe resolver patch?
>
> My bad, I haven't gotten to testing it yet :(.  One concern was that
> you mention the routines you're using are thread safe under 5.4 and
> better and I wondered if there was an impact on 4.x users?  I will
> try and get this tested soon, as I want it in the next patchset.

It's a good question. 4.x completely lacks a thread-safe resolver 
library, and getaddrinfo() makes up for this by maintaining a Giant 
lock on all resolver functions. This can result in painful delays while 
threads block on name resolution.

Which is worse? Occasionally crashing java using the non-thread-safe 
resolver, or potentially causing significant resolution delays? I worry 
about the potential for breaking mostly-working installations. Then 
again, the non-thread-safe resolver may already be doing a better job 
of breaking them.

- -landonf 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFCzEEclplZCE/15mMRAvP8AKCLo5SBgTV/21zuz76QpkAW4BoH+QCfXyfN
c9kNkbmG9mbMhpZc2AXE/vY=
=Bxo3
-----END PGP SIGNATURE-----