PHWinfo - Afficher un message

16/05/2007, 15h27

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.

16/05/2007, 15h27	#8
Roy Smith Messages: n/a Hébergeur:	Re: Why Ping Requires RAW Sockets? 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.