Could anyone tell me why we use RAW sockets for PING and not TCP or
UDP sockets?
Please tell me...

regards,
deep

In article <1179224732.225443.81100@w5g2000hsg.googlegroups.c om>,
Deep <mail2sukhdeep@gmail.com> wrote:
>Could anyone tell me why we use RAW sockets for PING and not TCP or
>UDP sockets?
>Please tell me...

There is a "tcpping" program available.

UDP doesn't have any mechanism for requiring (or requesting) that
the other end send a reply of any sort.

TCP does implicitly request that a reply be sent (either a
connection handshake or a refusal), but if the other end replies
with a connection handshake, that ties up resources on the other
end until you send a "nevermind!" packet releasing them (or a timeout
occurs).

Traditional ping requests a reply but allows the other end to
promptly forget about the response, not tying up resources for it.

On May 15, 6:25 am, Deep <mail2sukhd...@gmail.com> wrote:
> Could anyone tell me why we use RAW sockets for PING and not TCP or
> UDP sockets?
> Please tell me...

Classic ping sends ICMP Echo Request messages, and listens for ICMP
Echo Reply messages. You can't explicitly generate ICMP messages with
TCP or UDP, so ping uses a raw socket and builds the messages "by
hand".

You might want to read the description of the origins of ping that the
original author (the late Mike Muus) wrote on his website. Check out
http://ftp.arl.mil/~mike/ping.html for "The Story of Ping".

In article <1179230845.795333.309570@k79g2000hse.googlegroups .com>,
Lew Pitcher <lpitcher@teksavvy.com> wrote:

> On May 15, 6:25 am, Deep <mail2sukhd...@gmail.com> wrote:
> > Could anyone tell me why we use RAW sockets for PING and not TCP or
> > UDP sockets?
> > Please tell me...
>
> Classic ping sends ICMP Echo Request messages, and listens for ICMP
> Echo Reply messages. You can't explicitly generate ICMP messages with
> TCP or UDP, so ping uses a raw socket and builds the messages "by
> hand".

There's nothing fundamental about the ICMP protocol which requires raw
sockets. The fact that we use raw sockets is just an artifact of the
commonly used Berkeley Socket API.

A different API (for example, WinSock) could easily implement other ways to
send ICMP packets which doesn't involve hand-crafting packets and sending
them out a raw socket.

On Tue, 15 May 2007 05:07:25 -0700, Lew Pitcher wrote:

> You might want to read the description of the origins of ping that the
> original author (the late Mike Muus) wrote on his website. Check out
> http://ftp.arl.mil/~mike/ping.html for "The Story of Ping".

Very good reading. Thank you!

M4

Roy Smith <roy@panix.com> wrote:
> In article <1179230845.795333.309570@k79g2000hse.googlegroups .com>,
> Lew Pitcher <lpitcher@teksavvy.com> wrote:

> > On May 15, 6:25 am, Deep <mail2sukhd...@gmail.com> wrote:
> > > Could anyone tell me why we use RAW sockets for PING and not TCP or
> > > UDP sockets?
> > > Please tell me...
> >
> > Classic ping sends ICMP Echo Request messages, and listens for ICMP
> > Echo Reply messages. You can't explicitly generate ICMP messages with
> > TCP or UDP, so ping uses a raw socket and builds the messages "by
> > hand".

> There's nothing fundamental about the ICMP protocol which requires raw
> sockets. The fact that we use raw sockets is just an artifact of the
> commonly used Berkeley Socket API.

True, although one still wouldn't use a "TCP" or "UDP" socket as the
OP is asking. It could be an "ICMP" socket. I guess the BSD folks
thought that the number of user-level uses of ICMP were few and far
enough between to not warrant anything besides raw sockets. (Wild
guess on my part)

rick jones
--
No need to believe in either side, or any side. There is no cause.
There's only yourself. The belief is in your own precision. - Jobert
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

In article <f2d5fb$ej9$1@usenet01.boi.hp.com>,
Rick Jones <rick.jones2@hp.com> wrote:

> Roy Smith <roy@panix.com> wrote:
> > In article <1179230845.795333.309570@k79g2000hse.googlegroups .com>,
> > Lew Pitcher <lpitcher@teksavvy.com> wrote:
>
> > > On May 15, 6:25 am, Deep <mail2sukhd...@gmail.com> wrote:
> > > > Could anyone tell me why we use RAW sockets for PING and not TCP or
> > > > UDP sockets?
> > > > Please tell me...
> > >
> > > Classic ping sends ICMP Echo Request messages, and listens for ICMP
> > > Echo Reply messages. You can't explicitly generate ICMP messages with
> > > TCP or UDP, so ping uses a raw socket and builds the messages "by
> > > hand".
>
> > There's nothing fundamental about the ICMP protocol which requires raw
> > sockets. The fact that we use raw sockets is just an artifact of the
> > commonly used Berkeley Socket API.
>
> True, although one still wouldn't use a "TCP" or "UDP" socket as the
> OP is asking. It could be an "ICMP" socket. I guess the BSD folks
> thought that the number of user-level uses of ICMP were few and far
> enough between to not warrant anything besides raw sockets. (Wild
> guess on my part)

I suspect the reason for this is that ICMP doesn't have anything
analogous to TCP and UDP's port numbers, which allow different processes
to share the protocol without interfering with each other.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Barry Margolin <barmar@alum.mit.edu> wrote:
> I suspect the reason for this is that ICMP doesn't have anything
> analogous to TCP and UDP's port numbers, which allow different processes
> to share the protocol without interfering with each other.

Of course it does (it's not called a "port", but it's certainly analagous
to it). Open up two windows. Start pinging the same remote host in each
window. Do the two ping programs interfere with each other? Every ICMP
Echo Request packet has an id field
(http://en.wikipedia.org/wiki/ICMP_Echo_Request). The target returns the
id to the sender in the ICMP Echo Reply packet.

The way it's usually implemented, it's up to the application to fill in the
id field with something useful. On unix systems using the Berkely API, the
obvious and universal choice is your process id. However, one could easily
imagine a different API where the kernel handles the allocation of "ICMP id
numbers" and ensures that no two processes can get the same id
concurrently. It might also handle the construction and routing of ICMP
headers entirely in the kernel. At that point, ICMP really starts to look
a lot more like UDP/TCP.

The Berkeley Socket API is so ubiquitous that people tend to think it's the
only way of doing things. In fact, many people find it difficult to
differentiate in their minds the protocol from the API. Many of the things
people think they know about the IP protocols are really things they know
about the BSAPI.

One of my favorite interview questions for somebody who claims "expert
knowledge of TCP/IP" or some such silliness on their resume is to ask them
to sketch out both sides of a trivial TCP client-server application on the
whiteboard. It usually takes a few hints, but eventually they converge on
something like socket/bind/listen/accept/read on one side and
socket/connect/write on the other. Then I draw them two timelines and ask
them to show me all the packets that go on the wire, starting with the TCP
three-way handshake. The good ones usually do that OK too. Then I ask
them to correlate each system call in the application skeletons they just
wrote with each packet that went out on the wire. That's where the fun
usually begins.

Roy Smith <roy@panix.com> writes:

>One of my favorite interview questions for somebody who claims "expert
>knowledge of TCP/IP" or some such silliness on their resume is to ask them
>to sketch out both sides of a trivial TCP client-server application on the
>whiteboard. It usually takes a few hints, but eventually they converge on
>something like socket/bind/listen/accept/read on one side and
>socket/connect/write on the other. Then I draw them two timelines and ask
>them to show me all the packets that go on the wire, starting with the TCP
>three-way handshake. The good ones usually do that OK too. Then I ask
>them to correlate each system call in the application skeletons they just
>wrote with each packet that went out on the wire. That's where the fun
>usually begins.

But that's a trick question! (A number of packets does not
correlate to system calls)

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

On May 15, 1:33 pm, Rick Jones <rick.jon...@hp.com> wrote:

> True, although one still wouldn't use a "TCP" or "UDP" socket as the
> OP is asking. It could be an "ICMP" socket. I guess the BSD folks
> thought that the number of user-level uses of ICMP were few and far
> enough between to not warrant anything besides raw sockets. (Wild
> guess on my part)

I think another issue was one of policy. I don't think they wanted to
implement an ICMP access policy in the kernel. That meant any process
that was going to do anything with ICMP had to be root. So there was
really no advantage to a formal ICMP interface. One of the main
reasons we need a TCP and a UDP interface is to prohibit non-root
processes from stepping on each others' toes.

DS

On Wed, 16 May 2007 09:27:54 -0400, Roy Smith <roy@panix.com> wrote:
....
> The Berkeley Socket API is so ubiquitous that people tend to think it's the
> only way of doing things. In fact, many people find it difficult to
> differentiate in their minds the protocol from the API. Many of the things
> people think they know about the IP protocols are really things they know
> about the BSAPI.
>
> One of my favorite interview questions for somebody who claims "expert
> knowledge of TCP/IP" or some such silliness on their resume is to ask them
> to sketch out both sides of a trivial TCP client-server application on the
> whiteboard. It usually takes a few hints, but eventually they converge on
> something like socket/bind/listen/accept/read on one side and
> socket/connect/write on the other. Then I draw them two timelines and ask
> them to show me all the packets that go on the wire, starting with the TCP
> three-way handshake. The good ones usually do that OK too. Then I ask
> them to correlate each system call in the application skeletons they just
> wrote with each packet that went out on the wire. That's where the fun
> usually begins.

And that's why I like Stevens' TCP/IP Illustrated vol 1 better than his
UNIX Network Programming vol 1.

It took me many years to realize that I understood BSD sockets better
in terms of the protocols it tries (semi-successfully) to hide, than
in terms of the API itself.

/Jorgen

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!

Jorgen Grahn <grahn+nntp@snipabacken.dyndns.org> wrote:
> And that's why I like Stevens' TCP/IP Illustrated vol 1 better than
> his UNIX Network Programming vol 1.

Prior to Stevens' "UNIX Network Programming, Vol 1" there was his book of
the same name, but in a single volume, published in 1990 titled simply
"UNIX Network Programming". It mentioned the TCP/UDP/IP, XNS, SNA, netBIOS,
OSI, and UUCP protocols and briefly compared them. It also went into some
depth on an alternate API at the time to sockets: TLI.

Because the older edition of his book dealt with more than just the sockets
API and morer than just the TCP/IP protocol, it was able to provide some
genuine context for design decisions made in the APIs due to the alternate
protocols that were still viable at the time.

Jim Logajan <JamesL@Lugoj.com> writes:
> Because the older edition of his book dealt with more than just the sockets
> API and morer than just the TCP/IP protocol, it was able to provide some
> genuine context for design decisions made in the APIs due to the alternate
> protocols that were still viable at the time.

OSI was being aggreed to in ISO at about the same time that
internetworking protocol was being formulated. the big difference was
that OSI was a traditional single networking protocoal ... and the work
on internetworking protocol was realization that it would be necessary
to connect/internetwork lots of different networks.

OSI was never really viable ... it was just mandated by some number of
govs. ... including in the states where there was a gov. directive to
eliminate the internet and replace it with OSI ... along with stuff like
GOSIP that continued (at least) into the early 90s.

there were numerous issues. ISO standards operation hasn't a requirement
to demonstrate any operational or feasable implementation in order to be
passed as standard ... while IETF has required demonstration of
multiple, different, interoperable implementations.

ISO compounded the OSI problems with rules that there couldn't be any
networking standards work on anything that violated OSI.

there was an attempt to get some high-speed protocol standardization
work done in the ISO chartered ANSI X3S3.3 (US body responsible for
networking standards). Work was declined because it violated OSI:

1) it supported LAN/MAC interface which violates OSI because the LAN/MAC
interface sits somewhere in the middle of OSI layer 3.

2) it supported internetworking protocol which violates OSI because it
is a non-existant layer (in the OSI model) that sort of sits between
(OSI) layer 3 and (OSI) layer 4

3) it provided for going directly form transport/layer4 interface direct
to LAN/MAC interface ... violating OSI by bypassing the interface
between OSI layers 3&4.

Roy Smith <roy@panix.com> writes:

> There's nothing fundamental about the ICMP protocol which requires raw
> sockets. The fact that we use raw sockets is just an artifact of the
> commonly used Berkeley Socket API.
>
> A different API (for example, WinSock) could easily implement other ways to
> send ICMP packets which doesn't involve hand-crafting packets and sending
> them out a raw socket.

For fun, I implemented an ICMP ping API under the Berkeley socket
implementation supported by the NetWare TCP/IP stack way back when.
It was fun, but it's really pretty pointless to implement a general
API for something that's only going to be used by one, or maybe two
programs, ever... and the second program will probably be copied from
the first, anyway. Might as well put all the effort into the program
instead of the API.

-don provan

On Fri, 18 May 2007 17:57:57 -0000, Jim Logajan <JamesL@Lugoj.com> wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.dyndns.org> wrote:
>> And that's why I like Stevens' TCP/IP Illustrated vol 1 better than
>> his UNIX Network Programming vol 1.
>
> Prior to Stevens' "UNIX Network Programming, Vol 1" there was his book of
> the same name, but in a single volume, published in 1990 titled simply
> "UNIX Network Programming". It mentioned the TCP/UDP/IP, XNS, SNA, netBIOS,
> OSI, and UUCP protocols and briefly compared them. It also went into some
> depth on an alternate API at the time to sockets: TLI.
>
> Because the older edition of his book dealt with more than just the sockets
> API and morer than just the TCP/IP protocol, it was able to provide some
> genuine context for design decisions made in the APIs due to the alternate
> protocols that were still viable at the time.

Thanks. Actually, this second edition still covers TLI (or rather its
decendant, XTI). I never really read that chapter (and I suspect most
others don't either). I blank out whenever OSI is mentioned.

/Jorgen

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!