Date: Wed, 6 Jul 2005 13:37:46 -0700 From: Landon Fuller <landonf@threerings.net> To: Greg Lewis <glewis@eyesbeyond.com> Cc: freebsd-java@freebsd.org Subject: Re: [PATCH] jdk1.4.2, getsockname(), and ECONNRESET Message-ID: <1aebb438473c6cf4694df15d071be468@threerings.net> In-Reply-To: <20050621210125.GA96069@misty.eyesbeyond.com> References: <ac03de2a0609c35568cde420cf34043b@threerings.net> <20050621210125.GA96069@misty.eyesbeyond.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1aebb438473c6cf4694df15d071be468>