JRuby

I fixed this on trunk (commit 4267) but had a weird time matching MRI/socket library behavior for localhost so I am luke warm about committing this to 1.0 branch until someone has verified/used this new TCPSocket.new code. Can the original reporter try their code against trunk to see if things are peachy?

Leaving open to indicate it is candidate for 1.0 branch.

Thanks for the update. I've tried the trunk, and and can now call TCPSocket.new() with four parameters. However, the behaviour is really weird. I've been running Wireshark to figure out what is actually happening, and I just can't understand it. It looks like two TCP sockets are opened - one on the port I want, and one on a random port. It looks like the action is happening on both sockets, but, because the random one is opened first, that one completes first. Very strange...

Out of curiousity do you see these two connection with the two parameter version as well? I am wondering if the SocketChannel class we use on the socket is responsible for the second connection. If so, then the two parameter connection should do the same thing.

I think that the four parameter version worked fine when the src_port was specified as 0. It was only when I used an explicit port number that things went wrong.

Thanks!

Sounds like this is a safe backport to 1.0. Tom, can you take it?

This has problems which still need addressing on trunk much less moving to branch. We at least accept four params now, but something is not quite right. We appear to make multiple port connections.

Bumping off 1.0.2...Tom, if you think it can get into 1.0.2 go ahead.

Well according to the RubyTCPSocket source that I'm looking at (trunk rev 4998) of JRuby 1.1, it is doing nothing wrong as far as Java NIO is concerned. The problems with an ephemeral local port being ("accidentally") opened and then the specified local port being opened for connected socket aren't happening on Windows XP and JDK 1.6.

When attempting the following command line args: -C -e "require 'socket'; TCPSocket.new('mail.grahamis.com', 25, 'localhost', 1)" which should refuse connection, I get the following TCP activity on Windows

<pre>
C:\>netstat -p TCP -n
TCP 192.168.2.100:1086 74.50.13.92:143 ESTABLISHED
TCP 192.168.2.100:1087 74.50.13.92:143 ESTABLISHED

C:\>netstat -p TCP -n
TCP 127.0.0.1:1 74.50.13.92:25 SYN_SENT
TCP 192.168.2.100:1086 74.50.13.92:143 ESTABLISHED
TCP 192.168.2.100:1087 74.50.13.92:143 ESTABLISHED

-e:1:in `new': Connection refused (Errno::ECONNREFUSED)

C:\>netstat -p TCP -n
TCP 192.168.2.100:1086 74.50.13.92:143 ESTABLISHED
TCP 192.168.2.100:1087 74.50.13.92:143 ESTABLISHED
</pre>

No junk local ports got opened as far as netstat was concerned. I would have expected to see something like this if there was a zombie ephemeral port opened:

TCP 127.0.0.1:2021 0.0.0.0:0 UNKNOWN

Alex should have another test?

This doesn't seem quite right on trunk either, so I think it's still broken. Bumping off dead 1.0 branch.

Punting...it's been around forever and nobody seems to want to/know how to tackle it.

I made a small change for this that I think should resolve remaining issues

Before, a SocketChannel was opened, the related socket had "bind" and "connect" called on it, and then SocketChannel.finishConnect was called. I suspect this last call may have caused the channel to try to re-open a new connection and possible abandon the old one (which would then go into TIME_WAIT and eventually disconnect. Unfortunately I was unable to reproduce the double-socket thing...I think it's too transient to notice with netstat -a.

My modification simply constructs a Socket object, calls bind and connect, and then gets the underlying channel. This will hopefully eliminate the double-socket you noticed. Please confirm.

I also am not sure the best way to test this, so if you can please submit a simple test case that does not depend on an outside server, it would be most appreciated.

Committed in r9162.