kaba@acdhq.north.de (Kai Bartels) (11/28/90)
Hy! I'm currently workin on an implementation of tcp-ip an during this work i realised that i really don't know how fragments are representated on a serial line. I don't think it's possible to have it in the same way as it is on ethernet, 'cause on a serial line you have to know the length of the fragment BEFORE you get it, so you don'y miss the end. So the question is: can anybody tell me which RFC to look at? Thanks in advance, Kai -------------------- Kai Bartels | kaba@acdhq.UUCP | Where do you get your information Hudemuehler 37 | kaba@acdhq.north.de | From a dream or a 24-inch-screen? D-2800 HB 41 | G14B@DHBRRZ41.BITNET | <Thinkman>
dls@mentor.cc.purdue.edu (David L Stevens) (11/28/90)
In article <18466181.ARN13a9@acdhq.north.de>, kaba@acdhq.north.de (Kai Bartels) writes: > Hy! > I'm currently workin on an implementation of tcp-ip an during this work > i realised that i really don't know how fragments are representated on a > serial line. I don't think it's possible to have it in the same way as > it is on ethernet, 'cause on a serial line you have to know the length of > the fragment BEFORE you get it, so you don'y miss the end. > > So the question is: can anybody tell me which RFC to look at? RFC 791. :-) The IP "length" field is the length of the packet, not the datagram. That is, for a fragment, the "length" field tells you how big the fragment is, but you don't know how big the datagram is until you've received the last of its fragments (RFC 791, page 27, line 1). So, for individual packets, you can read the min header (20 octets) and it tells you how much header & data is there. But, if you want to make your life easier, you can also add your own (or someone else's) link-level protocol and encapsulate IP and whatever else in that. You *will* need this if you do more than just IP stuff on the line. ARP doesn't make much sense on a 2-node network, but if it's more than just a toy implementation, it's better to provide self-identifying packets and while you have that, you might as well add a length field. If you like Ethernet, just send Ethernet "frames" serially. You probably will also want to check out RFC 1055 and maybe 1144. 1055 Romkey, J.L. Nonstandard for transmission of IP datagrams over serial lines: SLIP. 1988 June; 6 p. (Format: TXT=12911 bytes) 1144 Jacobson, V. Compressing TCP/IP headers for low-speed serial links. 1990 February; 43 p. (Format: TXT=120959, PS=534729 bytes) -- +-DLS (dls@mentor.cc.purdue.edu)
enag@ifi.uio.no (Erik Naggum) (11/29/90)
In article <1882@mentor.cc.purdue.edu>, David L Stevens writes:
You probably will also want to check out RFC 1055 and maybe 1144.
1055 Romkey, J.L. Nonstandard for transmission of IP datagrams over serial
lines: SLIP. 1988 June; 6 p. (Format: TXT=12911 bytes)
1144 Jacobson, V. Compressing TCP/IP headers for low-speed serial links.
1990 February; 43 p. (Format: TXT=120959, PS=534729 bytes)
In addition to these two documents, a full-blown point-to-point
protocol has been developed. (Serial lines is the archetypical
point-to-point link...)
1172 Perkins, D.; Hobby, R. Point-to-Point Protocol (PPP) initial
configuration options. 1990 July; 38 p. (Format: TXT=76132 bytes)
You may also find this document interesting.
--
[Erik Naggum] Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY
Mail: <erik@naggum.uu.no>, <enag@ifi.uio.no>
My opinions. Wail: +47-2-836-863
--