This file describes some of the details of the IP implementation for Cedar. Usage: The interface is IP.mesa. In order to receive IPs, you must use CreateIPHandle to describe the datagrams that you are interested in. It will return a handle which is used in calls to Receive. It can also be passed to Send to cause the header to be filled in for you when you send a datagram. Get rid of it with DestroyIPHandle. To send a datagram, allocate or reuse a Datagram record. Fill in the data, inHdr.options, dataLength and optionLength fields and call Send. If you like, fill in the rest of the inHdr fields except for the version, length, fragment, and checksum fields, and call SendSpecific. The datagrams that Receive returns are yours to keep. Drop them on the floor or save them and reuse them. You can give a timeout value to Receive to make it return with no datagram (returns NIL). Receive may raise IP.Error if you destroy the handle it is using while a call is pending. PrintDatagram is useful for debugging. It knows how to print interesting fields from the header and from an ICMP datagram. Implementation: The initialization code for IPOpsImpl registers a SpyProc with the Pilot communications software to capture all the incoming IP datagrams. An unfortunate side effect of this is that PupWatch is off-limits while the IP package is running. You can shut down the IP software and start it up again my calling IPOpsImpl.ShutDownIP[] and StartupIP[], neither of which are exported (use the debugger). [ShutdownIP will leave a couple of processes lying around, but they shouldn't hurt anything.] The spy proc captures all datagrams with type code 1005b and check that they have valid checksums and length fields. If the datagram is a fragment, it calls IPReassembly.Reassemble, which may return an assembled datagram. If so, or if we did not call Reassemble to begin with, we call IPQueue.QueueDatagram to place this datagram on the appropriate input queue. IPReassembly is a monitor protecting the list of datagram fragments that have not been successfully reassembled. A process forked by IPOpsImpl.StartupIP calls in every few seconds to decrement the TimeToLive fields of the fragments, possibly causing some to be discarded. IPQueue is a monitor protecting all the datagram input queues. It contains a list of all the valid handles. The handles have a list of queued datagrams and a CONDITION variable for the Receive procedure to wait on. Encapsulation of packets: Ethernet types: 1004B: IP host to front-end -- Arpanet address is destination 1005B: front-end to IP host -- Arpanet address is source EthernetPacket: TYPE = MACHINE DEPENDENT RECORD [ dest, source: [0..377B], -- standard Ethernet packet header type: CARDINAL, -- standard Ethernet packet header arpaAdr: ArpanetAddress, ipPkt: IPPacket] ArpanetAddress: TYPE = MACHINE DEPENDENT RECORD [ net: [0..377B], -- always 10 for Arpanet host: [0..377], imp: CARDINAL]; Note that an ArpanetAddress, taken as a 32-bit number with the high-order word first (backward from Mesa doubleword order) is the same as an Internet address. Name table: IPName is an interface for translating between Internet host names and addresses, using a previously contructed name table. There is also a procedure for building a new name table from the NIC's "Hosts.txt" file. See the interface for details. A separate program BuildNameTable.bcd (not part of IPImpl) simply provides a command-line interface to the procedure IPName.Build. The command "BuildNameTable fileName" will construct a new version of IP.nameTable from the information in the specified file. vIP.tioga Last Edited by: Nichols, August 31, 1983 5:26 pm Last Edited by: Taft, January 21, 1984 5:56:39 pm PST ΚΗ– "cedar" style˜J™J™0J™5J˜J˜KJ˜˜J˜ΗJ˜J˜“J˜J˜žJ˜J˜zJ˜—˜J˜θJ˜J˜ιJ˜J˜J˜J˜ΦJ˜—˜˜J˜=J˜8J˜˜1J˜;J˜2J˜J˜J˜—˜1J˜(J˜J˜J˜—J˜žJ˜——˜ J˜σJ˜J˜‚J˜——…—.k