• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: OT ping sample code
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OT ping sample code


  • Subject: Re: OT ping sample code
  • From: Justin Walker <email@hidden>
  • Date: Tue, 13 Jan 2004 09:16:28 -0800

On Monday, January 12, 2004, at 11:40 PM, Igor garnov wrote:
[snip]
Is this true for any port?

The behavior on contacting a specific port on a specific machine depends solely on the OS or an intervening firewall. Sometimes, it will reply to a connection request with a PORT_UNREACHABLE ICMP datagram; but sometimes, it will just not reply. You can't predict ahead of time, even if you know the OS.

When I try to establish connection to a remote host, I use TCP over IP.
TCP is just a mechanism that ensures that all my packets reach their destination or informs me if it is absolutely impossible to deliver any of them.

Actually, TCP will fail (eventually) if it's impossible to deliver *any* packet, although "packet" is a misnomer here (TCP doesn't deal in packets).

So, this lets me believe that there MIGHT be different types of errors depending on the situation.
If the host is offline, it is IP that reports the error, because it is IP that cannot deliver data.

No. IP doesn't care whether the packets it sends get to where they are going. As you mention above, it's TCP that cares.

It's possible that an intervening router may tell you HOST_UNREACHABLE (via ICMP), but you can't bank on that.

But if the host is online but is not listening to the port I am trying to connect to, IP delivers data to the remote machine and gives it to TCP (there is no error from the IP's point of view). And after that TCP sees that there is no application that has opened the port specified in the freshly received packet. and rejects it. Then it reports the error, but this error should probably be different from that the IP returns.

If there's an intervening firewall, you may get no reply, because the firewall will quietly swallow your attempt at a connection.

I'm not saying this is 'best practise', but the combination of all of this
seems to work and I've used it for quite a while now. I'm not sure how this
will work across the internet, but then my ping only needs to work on an
intranet (so I don't care).

That's exactly what I need! I am interested in intranet, too.
That 'discard port' - I have seen it on the list off well known ports, but never knew what it does.

This is one of the ports that 'modern' systems will have disabled by default. It is intended for diagnostic purposes, and serves no (other) useful purpose.

In short, attempts to 'ping' a remote host are increasingly likely to fail (false negatives). If you use TCP as the mechanism for the ping, I'm unclear on why you wouldn't just connect to your application's port in the first place. In most other cases, you are just wasting bandwidth, for no gain.

Regards,

Justin

--
Justin C. Walker, Curmudgeon-At-Large *
Institute for General Semantics | Men are from Earth.
| Women are from Earth.
| Deal with it.
*--------------------------------------*-------------------------------*
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: OT ping sample code (From: Igor garnov <email@hidden>)

  • Prev by Date: AirPort drivers - IOClass names and keys
  • Next by Date: Re: Basic Question: Internet Content Filter
  • Previous by thread: Re: OT ping sample code
  • Next by thread: Re: OT ping sample code
  • Index(es):
    • Date
    • Thread