3 ms·

I remember that back in the 90s it was very hard for me on MacOS to debug network applications when the connection was interrupted or lost due to a crash or a t

I remember that back in the 90s it was very hard for me on MacOS to debug network applications when the connection was interrupted or lost due to a crash or a test. It took minutes until the same port could be used again, even when another local port was chosen. To detect a lost connection people used ping-pong signals in their application protocol. Since then network stacks seem to have improved tremendously but I thought it's still customary to ping the other side from time to time. Is that not enough to solve the problem?

ianai 9y ago
As a lover of the ICMP ping, hosts which do not respond to ping are increasingly prevalent. I’m sure it’s enough to wreck that usage.
- zaarn 9y ago
  On IPv4, blocking ICMP has sadly become the norm since some people abused it for ICMP storms. On IPv6 it is strongly recommended not to block ICMPv6 since it routes highly important information back to the sender or forwards to the receiver (like when MTU is reached)
  - zrm 9y ago
    > On IPv6 it is strongly recommended not to block ICMPv6 since it routes highly important information back to the sender or forwards to the receiver (like when MTU is reached) The same is true for IPv4. Path MTU discovery is not new for IPv6. Most systems set the DF (don't fragment) bit by default.
    - zaarn 9y ago
      On IPv4 it's a bit of a problem because of the number of legacy middleboxes that block things they don't know, some olders routers have problems with DF (always fun to debug). IPv6 makes ICMP path MTU discovery part of the protocol and disabling ICMP can (and will) wreak havoc on reliable connections (though TCP can compensate)
      - zrm 9y ago
        > On IPv4 it's a bit of a problem because of the number of legacy middleboxes that block things they don't know, some olders routers have problems with DF (always fun to debug). The DF bit has been part of IPv4 since day one. There is no excuse for anything in production to not support it. That doesn't mean broken routers don't exist, but "obviously broken router is obviously broken" is properly resolved by removing it from service and possibly finding a suitable museum to put it in. That isn't the issue. IPv6 doesn't have a DF bit (it's always implied), but sending an IPv4 packet with DF set has the same effect, and most modern systems do that. Most routers will then correctly send back the "Packet Too Big" ICMP message as appropriate. But if the firewall drops that ICMP message, it's just as problematic as doing it for IPv6. The result is the same.
- jonathanstrange 9y ago
  Sorry I wasn't specific enough, I didn't mean ICMP ping but some application protocol specific periodic request-acknowledgment exchange within a TCP connection in order to check that the connection is still alive regardless of what the OS socket layer says. Many application protocols have this, at least older ones, and I always thought the reason for it is that OS TCP stacks are sometimes unreliable or have unreasonable timeouts. It's been a long time I've done network programming, though...

ianai 9y ago

As a lover of the ICMP ping, hosts which do not respond to ping are increasingly prevalent. I’m sure it’s enough to wreck that usage.

zaarn 9y ago
On IPv4, blocking ICMP has sadly become the norm since some people abused it for ICMP storms. On IPv6 it is strongly recommended not to block ICMPv6 since it routes highly important information back to the sender or forwards to the receiver (like when MTU is reached)
- zrm 9y ago
  > On IPv6 it is strongly recommended not to block ICMPv6 since it routes highly important information back to the sender or forwards to the receiver (like when MTU is reached) The same is true for IPv4. Path MTU discovery is not new for IPv6. Most systems set the DF (don't fragment) bit by default.
  - zaarn 9y ago
    On IPv4 it's a bit of a problem because of the number of legacy middleboxes that block things they don't know, some olders routers have problems with DF (always fun to debug). IPv6 makes ICMP path MTU discovery part of the protocol and disabling ICMP can (and will) wreak havoc on reliable connections (though TCP can compensate)
    - zrm 9y ago
      > On IPv4 it's a bit of a problem because of the number of legacy middleboxes that block things they don't know, some olders routers have problems with DF (always fun to debug). The DF bit has been part of IPv4 since day one. There is no excuse for anything in production to not support it. That doesn't mean broken routers don't exist, but "obviously broken router is obviously broken" is properly resolved by removing it from service and possibly finding a suitable museum to put it in. That isn't the issue. IPv6 doesn't have a DF bit (it's always implied), but sending an IPv4 packet with DF set has the same effect, and most modern systems do that. Most routers will then correctly send back the "Packet Too Big" ICMP message as appropriate. But if the firewall drops that ICMP message, it's just as problematic as doing it for IPv6. The result is the same.
jonathanstrange 9y ago
Sorry I wasn't specific enough, I didn't mean ICMP ping but some application protocol specific periodic request-acknowledgment exchange within a TCP connection in order to check that the connection is still alive regardless of what the OS socket layer says. Many application protocols have this, at least older ones, and I always thought the reason for it is that OS TCP stacks are sometimes unreliable or have unreasonable timeouts. It's been a long time I've done network programming, though...