Socket doesn't get EOF

Hey, i've got an irc bot of over 3000 lines of perl. I test for EOF on occasion and do a reconnect if eof is detected. This works greatly for instances as when the socket times out or is disconnected in most manors. It doesn't although register an eof when pppd dies. I realy don't know if this might be specific to perl or if even in C this is an issue.

Quoted 6 lines · K-sPecial

Hey, i've got an irc bot of over 3000 lines of perl. I test for EOF on occasion and do a reconnect if eof is detected. This works greatly for instances as when the socket times out or is disconnected in most manors. It doesn't although register an eof when pppd dies. I realy don't know if this might be specific to perl or if even in C this is an issue.

This is a frequently-asked question about TCP/IP.

No, you won't get EOF. No, it's not a bug. It's a feature, and it's by design. The TCP layer sees IP as a connectionless datagram service, and tries its best to deliver the data the application provides. IP sees the datalink layers as unrelated to any particular transport, so when a datalink layer goes down, the transport (such as TCP) isn't involved. If IP can route around the problem, it does so. If it can't, it drops the packets and hopes that either (A) the link comes back 'soon' or (B) the transport gives up eventually.

If you want a shorter timeout, set a timer in your application.

Thanks, that was very informative, it made sense and I much appreciate the prompt response. I have added a timeout on the socket and will get a glimpse of what happens next time pppd dies.

Quoted 3 lines · K-sPecial

Thanks, that was very informative, it made sense and I much appreciate the prompt response. I have added a timeout on the socket and will get a glimpse of what happens next time pppd dies.

You can also have pppd clobber the application via the /etc/ppp/ip-down script. I'd suggest that doing so is a mistake. If the link comes back (it was just a short glitch), then the application fails for no reason. If the network is designed with multiple paths, then there's really no good way to know when (or if) to kill the application.

Moreover, you'd have no way to know if some intermediate router failed, and you'd likely want to have the application "notified" in some way if that were to happen for the same reason that you want pppd to kill the application. If you can't detect router failure in practice, is there much additional value to detecting local interface failure?

Well, yes and no. In the way of the bot, not drasticly. Although the other day I was programming some perl that needed to know when the computer was online and when it wasn't. I realy didn't give it as much thought as I could have, but resorted to the resolution of a popular name server, such as internic.net. This of course can also have problems

when your DNS server(s) happens to not cooperate. Honestly i'm sure this isn't the correct manor to go about such a thing, but for what I needed it for, it should suffice. I was going to test for interfaces being up, which would work in the case of pppd, just not in the case of say DSL where your interface can obviously still be up yet your modem isn't online.

But as to your question, I would say there is, when you just need to know, period, if you can successfuly access a remote node via the Internet, and don't actualy need the support of an exact cause.

Even if the interfaces are up and the modem is "on line," that doesn't mean that any particular host is actually reachable. That sort of global knowledge just isn't knowable, except in retrospect: if the connection times out, then that host obviously can't be reached.

That's what timeouts are for. You can use the existing default timeout provided by TCP, or (if that's too long) you can set up your own timer with alarm() or similar functions.

Quoted 4 lines

Even if the interfaces are up and the modem is "on line," that doesn't mean that any particular host is actually reachable. That sort of global knowledge just isn't knowable, except in retrospect: if the connection times out, then that host obviously can't be reached.

Well there the problem lies within, the script was meant to to check if a port was open every so often, if it's down, check if your online, then possibly wait again to see if it opens back up, say 10 minutes (maybe the computer rebooted, maybe crontab will restart it), check again if online, then point the hostname to a different ip and start checking if the old host is back up again (so I can change it back). So just checking if I could access the host is what I was *double* checking, of course I couldn't rely on just the fact that I can't reach the port, before updating it to a new ip.

Quoted 3 lines

That's what timeouts are for. You can use the existing default timeout provided by TCP, or (if that's too long) you can set up your own timer with alarm() or similar functions.

Yup, i'm not sure but it seems the timeout optino that IO::Socket uses is just a connect timeout, it didn't seem to register when pppd died, could be wrong.

What's the point?

If the system is isolated from the world, then periodically noticing that the 'port' still isn't reachable, and switching to a different IP address should make no difference at all.

Again, that's not a bug. It's a design feature of TCP/IP. Links going up and down intentionally do _not_ cause connections to fail.

If you care about particular interfaces for some reason, then use SIOCGIFCONF to read the kernel's interface table or open a routing socket (PF_ROUTE) and listen for interface add/delete messages.

Quoted 3 lines

If the system is isolated from the world, then periodically noticing that the 'port' still isn't reachable, and switching to a different IP address should make no difference at all.

No, I think we are confusing each other, the port is open to begin with, the script changes it's ip so when the service goes unavailable it can be redirected to another computer running the same service. Basicly for when you don't have enough control of the computer the service is initialy running on to implment this from there.

Quoted 4 lines

If you care about particular interfaces for some reason, then use SIOCGIFCONF to read the kernel's interface table or open a routing socket (PF_ROUTE) and listen for interface add/delete messages.

Well, I don't care about the interface, since as I earlier stated, an interface can be up yet the internet still not accessable such as when your router is connected to you via ethernet.

Sure ... but why does it hurt to change the IP address when "the link" is down?

That's precisely the point.
The thing that makes a host unreachable might be zero, one, or many hops away. Worrying about the local interface(s) or about one particular local router is just useless.

Anway, as I've said multiple times now, you can determine precisely whether PPP is up or down (and get notifications when it goes up and down) by using any of SIOCGIFCONF, PF_ROUTE, or /etc/ppp/ip-{up,down}. You do not need to have the socket connection aborted with an error in order to find out this information.