RECV (BufPTR, prot, => result, src, dst, TOS, len, opt)

    where:

      BufPTR = buffer pointer
      prot = protocol
      result = response
        OK = datagram received ok
        Error = error in arguments
      len = length of buffer
      src = source address
      dst = destination address
      TOS = type of service
      opt = option data




 

September 1981                                                          
                                                       Internet Protocol
                                                           Specification



  When the user sends a datagram, it executes the SEND call supplying
  all the arguments.  The internet protocol module, on receiving this
  call, checks the arguments and prepares and sends the message.  If the
  arguments are good and the datagram is accepted by the local network,
  the call returns successfully.  If either the arguments are bad, or
  the datagram is not accepted by the local network, the call returns
  unsuccessfully.  On unsuccessful returns, a reasonable report must be
  made as to the cause of the problem, but the details of such reports
  are up to individual implementations.

  When a datagram arrives at the internet protocol module from the local
  network, either there is a pending RECV call from the user addressed
  or there is not.  In the first case, the pending call is satisfied by
  passing the information from the datagram to the user.  In the second
  case, the user addressed is notified of a pending datagram.  If the
  user addressed does not exist, an ICMP error message is returned to
  the sender, and the data is discarded.

  The notification of a user may be via a pseudo interrupt or similar
  mechanism, as appropriate in the particular operating system
  environment of the implementation.

  A user's RECV call may then either be immediately satisfied by a
  pending datagram, or the call may be pending until a datagram arrives.

  The source address is included in the send call in case the sending
  host has several addresses (multiple physical connections or logical
  addresses).  The internet module must check to see that the source
  address is one of the legal address for this host.

  An implementation may also allow or require a call to the internet
  module to indicate interest in or reserve exclusive use of a class of
  datagrams (e.g., all those with a certain value in the protocol
  field).

  This section functionally characterizes a USER/IP interface.  The
  notation used is similar to most procedure of function calls in high
  level languages, but this usage is not meant to rule out trap type
  service calls (e.g., SVCs, UUOs, EMTs), or any other form of
  interprocess communication.

  









 

                                                          September 1981
Internet Protocol



APPENDIX A:  Examples & Scenarios

Example 1:

  This is an example of the minimal data carrying internet datagram:

                                    
    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ver= 4 |IHL= 5 |Type of Service|        Total Length = 21      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Identification = 111     |Flg=0|   Fragment Offset = 0   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Time = 123  |  Protocol = 1 |        header checksum        |