From: Giro on 13 May 2010 15:24 Hi, I've written an application using Raw sockets. And sending the complete Layer2 frame. sock = socket(PF_PACKET,SOCK_RAW,htons(ETH_P_ALL)) A call like ret = send(sock, buff, buff_size,0); should returns the number of trasferred bytes. So far so good. Now, If I call the same function when the NIC link is down (cable not plugged) then I receive no error. Instead I receive the number of bytes trasferred. Is this is a special case for raw sockets? I guess sockets on higher layers like IP or TCP should return an error in such a case. Is there any possibility to register a callback routine for a link state change event? I guess I can check with an ioctl call to the driver whether the link is up or not. But a callback would be better ofcourse. Thanks for any help. Giray
From: Gordon Burditt on 22 May 2010 23:03 >I've written an application using Raw sockets. And sending the >complete Layer2 frame. >sock = socket(PF_PACKET,SOCK_RAW,htons(ETH_P_ALL)) > >A call like >ret = send(sock, buff, buff_size,0); >should returns the number of trasferred bytes. So far so good. Now, If >I call the same function when the NIC link is down >(cable not plugged) then I receive no error. Instead I receive the >number of bytes trasferred. > >Is this is a special case for raw sockets? I guess sockets on higher >layers like IP or TCP should return an error in such a case. A TCP connection shouldn't be aborted just because link state bounces, especially if nothing was being transmitted at the time. And in my experience, (the network cable sometimes falls out of my laptop), it doesn't. I can put it back and resume surfing the web with only a minor delay. If it's disconnected over about 45 seconds, then connections start breaking. The same applies to UDP "connections" where things like DNS lookups are retried after a timeout, whether link status bounces or not. *Eventually* they fail if the problem persists. >Is there any possibility to register a callback routine for a link >state change event? >I guess I can check with an ioctl call to the driver whether the link >is up or not. But a callback would be better ofcourse. Consider a system where the link state glitches briefly (although not at the hardware level) whenever DHCP renews. With a particular brand of DSL modem, that's every 30 seconds, 24x7. I don't think any packets actually get lost. Are you sure you actually want to pay attention to that, or should you pay attention to whether you got an answer to whatever it was you tried to send?
From: Nicolas George on 23 May 2010 05:10 Gordon Burditt wrote in message <mNydnRi-Xt6HBmXWnZ2dnUVZ_hWdnZ2d(a)posted.internetamerica>: > A TCP connection shouldn't be aborted just because link state > bounces, especially if nothing was being transmitted at the time. > And in my experience, (the network cable sometimes falls out of my > laptop), it doesn't. This is perfectly trye, but... > I can put it back and resume surfing the web > with only a minor delay. .... this does not prove it, as web surfing relies mostly on short independent connections.
From: Gordon Burditt on 24 May 2010 14:50 >> A TCP connection shouldn't be aborted just because link state >> bounces, especially if nothing was being transmitted at the time. >> And in my experience, (the network cable sometimes falls out of my >> laptop), it doesn't. > >This is perfectly trye, but... > >> I can put it back and resume surfing the web >> with only a minor delay. > >... this does not prove it, as web surfing relies mostly on short >independent connections. It does if you attempt the connection AFTER the cable falls out, notice the page isn't coming up, plug in the cable, and the page appears.
|
Pages: 1 Prev: tutorial or guide to terminal settings? Next: Is this Regular Expression for UTF-8 Correct?? |