Ping Class java

[Guenter Dannhaeuser]

Perhaps it is actually correct-!!, and you seeing , either something in the
jvm or you are seeing some real latency in the network for some reason.
[...]
but to get a result of 4771, 4802 ,would indicate the timer is not firing
in 500ms, which would indicate a possible jvm bug,(or a service tie up,
which would still be a bug)
perhaps you need to pass the code to sun along with details of your setup.
[...]

Hi Steve,

problem found: the JVM is running on Windows XP with netbios over
TCP/IP activated. On connect() the JVM tries to resolve the hostname
(java.net.InetAddress.getHostFromNameService, getHostByAddr).

Windows tries a netbios ns query on udp port 137 with a timeout of
1500ms, ignores any ICMP "port unreachable" packages and repeats this
two more times, adding up to a value of 4.5 seconds (!).

Deactivating netbios "fixes" this, but isn´t always an option ... any
ideas very welcome.

Greets,
guenter <gd--acm-org>

 

[steve]

Perhaps it is actually correct-!!, and you seeing , either something in
the
jvm or you are seeing some real latency in the network for some reason.
[...]
but to get a result of 4771, 4802 ,would indicate the timer is not
firing
in 500ms, which would indicate a possible jvm bug,(or a service tie up,
which would still be a bug)
perhaps you need to pass the code to sun along with details of your setup.
[...]

Hi Steve,

problem found: the JVM is running on Windows XP with netbios over
TCP/IP activated. On connect() the JVM tries to resolve the hostname
(java.net.InetAddress.getHostFromNameService, getHostByAddr).

Windows tries a netbios ns query on udp port 137 with a timeout of
1500ms, ignores any ICMP "port unreachable" packages and repeats this
two more times, adding up to a value of 4.5 seconds (!).

Deactivating netbios "fixes" this, but isn´t always an option ... any
ideas very welcome.

psodo code!!
if(total> timeoutMs){total=-1; // were on windows?
}

Greets,
guenter <gd--acm-org>

Jez, so do we file this under?:
1 a java bug.
2. a windows bug.
3. every other computer in the world is wrong.

That basically must mean that when windows is in it's internal routines that
take too long, that the timeouts for the java ports are being
'missed/overlooked/swallowed', it also accounts for why it's not showing up
on my windows SE . (nitbios is OFF)

Anyway, way to go !!!, on the bug hunt, did you get a packet sniffer on it,
how did you find it?

we could charge for this stuff. ( this is REAL WORLD programming) ;-)
( maybe roedy can get this on his web site)

personally if i were you, I would get a bug filed with sun, or add a fix into
the code so that if the ping reply is > the preset timeout value , you
ignore it, and re-ping.

me, I'm scrapping off all the windows stuff in our office and moving to linux
Steve

 

[Guenter Dannhaeuser]

Jez, so do we file this under?:
1 a java bug.
2. a windows bug.
3. every other computer in the world is wrong.

That basically must mean that when windows is in it's internal routines that
take too long, that the timeouts for the java ports are being
'missed/overlooked/swallowed', it also accounts for why it's not showing up
on my windows SE . (nitbios is OFF)

Anyway, way to go !!!, on the bug hunt, did you get a packet sniffer on it,
how did you find it?

we could charge for this stuff. ( this is REAL WORLD programming) ;-)
( maybe roedy can get this on his web site)

personally if i were you, I would get a bug filed with sun, or add a fix into
the code so that if the ping reply is > the preset timeout value , you
ignore it, and re-ping.

me, I'm scrapping off all the windows stuff in our office and moving to linux
Steve

Wondering why my gateway showed activity on udp 137, I used a Packet
Analyzer (Packetyzer) on this.

Turning Netbios off: no netbios name resolution, saving 4.5s.

But still Packetyzer showed reverse-ptr DNS lookups, causing
testConn() to return values > timeoutMs ... huh?

These are triggered in the ProxySelector checking wether SOCKS should
be used or not. Disabling proxy support with
ProxySelector.setDefault(null);

or, when creating the socket, with
Socket theSock = new Socket(Proxy.NO_PROXY);

prevents these lookups, passing the calls directly to the plain socket
implementation, resulting in correct timeouts.

Alternatively, using
InetAddress addr = InetAddress.getByAddress(String host, byte[]
addr);

e.g. with
InetAddress addr = InetAddress.getByAddress(ipHost,
IPAddressUtil.textToNumericFormatV4(ipHost));

where ipHost is a String in IP-Format instead of
InetAddress addr = InetAddress.getByAddress(String host);

bypasses reverse lookups and also validity checking on the host
string.
After all, I think I´ll stick to this, it´s still more elegant and
simpler than the solution with the thread observing connectFinish() on
a SocketChannel I posted in (e-mail address removed)

Just been on bugs.java.com:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5092063
describing these problems got closed with state "fixed". So this is
not a bug at all It´s just bad luck and two days lost.

guenter.

 

[Guenter Dannhaeuser]

On Thu, 20 Oct 2005 03:07:41 GMT, Roedy Green

The practical solution I would imagine is to put such hosts in your
HOSTS file and maintain them with TweakDUN to ensure the lookup is
fast.

Alan Krueger just also suggested this in [email protected] ,
I´ll reply here:

Problem is, that I do not know a priori which hosts I´m going to ping.
I gather these from parsing a (quite big) list of ips indicating
gateways that should work, but I have to test (some of) them to get a
collection of working ones. I´d have my application to constantly
update the lmhosts-file - not an option.

Anyway, bypassing the ProxySelector-Code (see
(e-mail address removed)) works for me.

greets, guenter. <gd--acm-org>

 

[steve]

Jez, so do we file this under?:
1 a java bug.
2. a windows bug.
3. every other computer in the world is wrong.

That basically must mean that when windows is in it's internal routines
that
take too long, that the timeouts for the java ports are being
'missed/overlooked/swallowed', it also accounts for why it's not showing up
on my windows SE . (nitbios is OFF)

Anyway, way to go !!!, on the bug hunt, did you get a packet sniffer on it,
how did you find it?

we could charge for this stuff. ( this is REAL WORLD programming) ;-)
( maybe roedy can get this on his web site)

personally if i were you, I would get a bug filed with sun, or add a fix
into
the code so that if the ping reply is > the preset timeout value , you
ignore it, and re-ping.

me, I'm scrapping off all the windows stuff in our office and moving to
linux
Steve

Wondering why my gateway showed activity on udp 137, I used a Packet
Analyzer (Packetyzer) on this.

Turning Netbios off: no netbios name resolution, saving 4.5s.

But still Packetyzer showed reverse-ptr DNS lookups, causing
testConn() to return values > timeoutMs ... huh?

These are triggered in the ProxySelector checking wether SOCKS should
be used or not. Disabling proxy support with
ProxySelector.setDefault(null);

or, when creating the socket, with
Socket theSock = new Socket(Proxy.NO_PROXY);

prevents these lookups, passing the calls directly to the plain socket
implementation, resulting in correct timeouts.

Alternatively, using
InetAddress addr = InetAddress.getByAddress(String host, byte[]
addr);

e.g. with
InetAddress addr = InetAddress.getByAddress(ipHost,
IPAddressUtil.textToNumericFormatV4(ipHost));

where ipHost is a String in IP-Format instead of
InetAddress addr = InetAddress.getByAddress(String host);

bypasses reverse lookups and also validity checking on the host
string.
After all, I think I´ll stick to this, it´s still more elegant and
simpler than the solution with the thread observing connectFinish() on
a SocketChannel I posted in (e-mail address removed)

Just been on bugs.java.com:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5092063
describing these problems got closed with state "fixed". So this is
not a bug at all It´s just bad luck and two days lost.

guenter.

2 days lost , well now you know you are a real programmer ;-)
i've done this before.

Steve

 

[steve]

I have documented this at http://mindprod.com/jgloss/socket.html

The practical solution I would imagine is to put such hosts in your
HOSTS file and maintain them with TweakDUN to ensure the lookup is
fast.

see http://mindprod.com/jgloss/hosts.html

you missed throwing windows away as a possible solution ;-)

steve

 

[Roedy Green]

you missed throwing windows away as a possible solution ;-)

The boss will say: "The customer is using windows. That's where the
big market is. That's where we have to develop first. It does not
matter what shit it is. Make it work by hook or by crook."

 

[steve]

The boss will say: "The customer is using windows. That's where the
big market is. That's where we have to develop first. It does not
matter what shit it is. Make it work by hook or by crook."

good job I do all my development on osx.
Then emulate the P.C with Virtual-PC, which incidentally crashes a way lot
less than a real P.C.

to be honest I have lost count of the number of winblows computers I have
smashed up, normally i just do the Keyboard.

Steve