Path: utzoo!attcan!uunet!snorkelwacker!apple!mips!sgi!shinobu!odin!ajit
From: ajit@sgi.com (Ajit Mayya)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: ARP described, for newcomers
Message-ID: <10457@odin.corp.sgi.com>
Date: 17 Jul 90 17:17:19 GMT
References: <1990Jul10.172440.15458@spectrum.CMC.COM> <2604@nems.dt.navy.mil> <1990Jul17.044417.17807@spectrum.CMC.COM>
Sender: news@odin.corp.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 25

In article <1990Jul17.044417.17807@spectrum.CMC.COM> lars@spectrum.CMC.COM (Lars Poulsen) writes:
>number).  The upper level protocols do not know ethernet addresses; when
>the datagram makes it to the ehernet device driver, it looks in a
>special table to see if the ethernet address for the receiver's IP
>address has been discovered. If not, it THROWS AWAY the datagram,
				      ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    No it doesn't. Atleast BSD based systems have a slot for hanging
    on to atleast one packet in the arp table entry. When the entry
    gets resolved, the packet is sent. Ofcourse, if it looks like there
    is going to be no incoming reply (after 3 retransmissions or whatever)
    the packet if freed up. Typically ARP resolution takes at most the
    order of milliseconds, and the packet is on its way without waiting
    for any retransmissions etc. 

    If two packets are sent to the same unresolved IP destintation,
    the first one will be queued. When the second one comes along, the
    first is dropped and the second is queued and so on and so forth.

    I haven't looked at the Host Requirements Document lately, but I
    think it requires implementations to hang on to atleast one packet.

-----------------------------------------------------------------------------
Ajit Mayya                  Silicon Graphics Inc., Advanced Systems Division
ajit@asd.sgi.com            Any opinions expressed above are mine, not SGI's
-----------------------------------------------------------------------------