× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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...




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.