Re: sockets connect() behaving strangely on local network -- RPG400-L

Hi Mike,

On Sun, 25 Aug 2002 meovino@estes-express.com wrote:
>
> Scott Klement, I hope you're out there reading...
>

Yep.

>
> I am trying both your tutorial example (CLIENTEX1) and the examples from
> the "Sorcerer's Guide..." redbook.  In both cases, if I attempt to make a
> connect() to a server on the internet and I disable the interface that the
> internet traffic travels on, the connect returns -1 as its return code
> immediately, which is what I want.

For this type of testing, it'd be better to use CLIENTEX2 since it
does a much better job of reporting the errors that occur, which will
give you a much better idea of what's happening.


>
> If I attempt to make a connect() to a server on our LAN (199.xxx.xxx.xxx)
> and disable all the interface that the LAN traffic travels on, the program
> sits at the connect() statement for about two minutes before returning -1
> as the return code.  Anyone have any idea why this is happening?
>

In order to really be able to answer your question, I'd really need
to understand all of the details of how your LAN(s) and internet
connections are set up.  I'd also need more details about the errors, and
probably to try a few different things to prove or disprove my theories...

However, I can take a guess:

Most likely, what's happening is that the sockets API is creating an IP
datagram ("packet") that is sent to the destination host as part of the
setup for that connection.

Normally, if the destination host doesn't want to received a connection on
the port, it sends back an ICMP datagram that indicates a "connection
refused" message.   Your system receives that message, and knows something
went wrong, so connect() returns -1.  Because it's receiving a message
back, it knows the connection won't work, so connect() ends just as soon
as the ICMP message is received.

When the destination host is actually not connected to the internet
because a link is down or something like that, one of the gateway/router
boxes (the one just before the linkage that's down) will know that the host
is unreachable, so it will send back an ICMP datagram that says "host
unreachable" or "network unreachable" or something of that nature.

However, none of this happens when connecting to a host on the LAN.  There
is no router or gateway involved in that situation.   There is nothing
to detect the error and send back an ICMP error message.  Do you see what
I'm saying?  The AS/400 would normally send DIRECTLY to the host since
they're on the same LAN.  Since the host isn't receiving the setup
datagram, and no other computers are involved in the connection process,
nothing ever sends back a "failure message."  Therefore, connect() will
simply sit there until it times out.

Another (less likely) possibility would be that the delay is happening
on the gethostbyname() instead of connect().  This could potentially
happen because your DNS server is available when the internet is down, but
not when the LAN is down.

My question to you is:  Why does it matter?  What are you trying to
accomplish?   Maybe I've got a solution for you...