home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Source Code 1993 July / THE_SOURCE_CODE_CD_ROM.iso / bsd_srcs / share / doc / smm / 15.net / 9.t < prev    next >
Encoding:
Text File  |  1991-04-17  |  5.6 KB  |  125 lines
  1. .\" Copyright (c) 1983, 1986 The Regents of the University of California.
  2. .\" All rights reserved.
  3. .\"
  4. .\" Redistribution and use in source and binary forms, with or without
  5. .\" modification, are permitted provided that the following conditions
  6. .\" are met:
  7. .\" 1. Redistributions of source code must retain the above copyright
  8. .\"    notice, this list of conditions and the following disclaimer.
  9. .\" 2. Redistributions in binary form must reproduce the above copyright
  10. .\"    notice, this list of conditions and the following disclaimer in the
  11. .\"    documentation and/or other materials provided with the distribution.
  12. .\" 3. All advertising materials mentioning features or use of this software
  13. .\"    must display the following acknowledgement:
  14. .\"    This product includes software developed by the University of
  15. .\"    California, Berkeley and its contributors.
  16. .\" 4. Neither the name of the University nor the names of its contributors
  17. .\"    may be used to endorse or promote products derived from this software
  18. .\"    without specific prior written permission.
  19. .\"
  20. .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
  21. .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  22. .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  23. .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
  24. .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  25. .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  26. .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  27. .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  28. .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  29. .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  30. .\" SUCH DAMAGE.
  31. .\"
  32. .\"    @(#)9.t    6.5 (Berkeley) 4/17/91
  33. .\"
  34. .nr H2 1
  35. .\".ds RH "Protocol/network-interface
  36. .br
  37. .ne 2i
  38. .NH
  39. \s+2Protocol/network-interface interface\s0
  40. .PP
  41. The lowest layer in the set of protocols which comprise a
  42. protocol family must interface itself to one or more network
  43. interfaces in order to transmit and receive
  44. packets.  It is assumed that
  45. any routing decisions have been made before handing a packet
  46. to a network interface, in fact this is absolutely necessary
  47. in order to locate any interface at all (unless, of course,
  48. one uses a single ``hardwired'' interface).  There are two
  49. cases with which to be concerned, transmission of a packet
  50. and receipt of a packet; each will be considered separately.
  51. .NH 2
  52. Packet transmission
  53. .PP
  54. Assuming a protocol has a handle on an interface, \fIifp\fP,
  55. a (struct ifnet\ *),
  56. it transmits a fully formatted packet with the following call,
  57. .DS
  58. error = (*ifp->if_output)(ifp, m, dst)
  59. int error; struct ifnet *ifp; struct mbuf *m; struct sockaddr *dst;
  60. .DE
  61. The output routine for the network interface transmits the packet
  62. \fIm\fP to the \fIdst\fP address, or returns an error indication
  63. (a UNIX error number).  In reality transmission may
  64. not be immediate or successful; normally the output
  65. routine simply queues the packet on its send queue and primes
  66. an interrupt driven routine to actually transmit the packet.
  67. For unreliable media, such as the Ethernet, ``successful''
  68. transmission simply means that the packet has been placed on the cable
  69. without a collision.  On the other hand, an 1822 interface guarantees
  70. proper delivery or an error indication for each message transmitted.
  71. The model employed in the networking system attaches no promises
  72. of delivery to the packets handed to a network interface, and thus
  73. corresponds more closely to the Ethernet.  Errors returned by the
  74. output routine are only those that can be detected immediately,
  75. and are normally trivial in nature (no buffer space, 
  76. address format not handled, etc.).
  77. No indication is received if errors are detected after the call has returned.
  78. .NH 2
  79. Packet reception
  80. .PP
  81. Each protocol family must have one or more ``lowest level'' protocols.
  82. These protocols deal with internetwork addressing and are responsible
  83. for the delivery of incoming packets to the proper protocol processing
  84. modules.  In the PUP model [Boggs78] these protocols are termed Level
  85. 1 protocols,
  86. in the ISO model, network layer protocols.  In this system each such
  87. protocol module has an input packet queue assigned to it.  Incoming
  88. packets received by a network interface are queued for the protocol
  89. module, and a VAX software interrupt is posted to initiate processing.  
  90. .PP
  91. Three macros are available for queuing and dequeuing packets:
  92. .IP "IF_ENQUEUE(ifq, m)"
  93. .br
  94. This places the packet \fIm\fP at the tail of the queue \fIifq\fP.
  95. .IP "IF_DEQUEUE(ifq, m)"
  96. .br
  97. This places a pointer to the packet at the head of queue \fIifq\fP 
  98. in \fIm\fP
  99. and removes the packet from the queue.
  100. A zero value will be returned in \fIm\fP if the queue is empty.
  101. .IP "IF_DEQUEUEIF(ifq, m, ifp)"
  102. .br
  103. Like IF_DEQUEUE, this removes the next packet from the head of a queue
  104. and returns it in \fIm\fP.
  105. A pointer to the interface on which the packet was received
  106. is placed in \fIifp\fP, a (struct ifnet\ *).
  107. .IP "IF_PREPEND(ifq, m)"
  108. .br
  109. This places the packet \fIm\fP at the head of the queue \fIifq\fP.
  110. .PP
  111. Each queue has a maximum length associated with it as a simple form
  112. of congestion control.  The macro IF_QFULL(ifq) returns 1 if the queue
  113. is filled, in which case the macro IF_DROP(ifq) should be used to
  114. increment the count of the number of packets dropped, and the offending
  115. packet is dropped.  For example, the following code fragment is commonly
  116. found in a network interface's input routine,
  117. .DS 
  118. ._f
  119. if (IF_QFULL(inq)) {
  120.     IF_DROP(inq);
  121.     m_freem(m);
  122. } else
  123.     IF_ENQUEUE(inq, m);
  124. .DE
  125.