Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-ses!hpcuhb!hpindda!subbu From: subbu@hpindda.HP.COM (MCV Subramaniam) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP Urgent Data Handling Message-ID: <6200027@hpindda.HP.COM> Date: 29 Sep 89 17:07:24 GMT References: <4982@omepd.UUCP> Organization: HP Information Networks, Cupertino, CA Lines: 40 >multi-character message is urgent and 4.3 BSD assumes the last byte. Also, >4.3 breaks large urgent messages into several segments with the URG bit >set and the urgent pointer pointing to just past the data *in each segment*. 4.3 TCP considers only one byte in the message as urgent. Therefore, if you call send() with 2000 bytes, the last byte will be considered urgent, and the SND.UP pointer will be updated to that value. Thereafter, every packet sent will have the URG flag set, but the URP in the packet will be equal to SND.UP. That is, each segment will contain the same value of URP in it. I believe 4.2 used to set URG flag and URP only in the segments in which the OOB byte is actually transmitted. (Someone correct me if I am wrong). >The receiver will believe each segment is an urgent message and each segment >will override the last saved urgent byte unless inlining is specified. This If, however, you call multiple send()s with MSG_OOB, then each segment sent will contain one urgent byte, and if the user has not received the last OOB byte, it will be overridden with the new one, and RCV.UP will be moved past the new URP received. The following bugs exist in 4.3 BSD urgent (OOB) data handling: 1. If you send Out of band bytes *too* frequently, i.e. send the next OOB before the first is acknowledged, then 4.3 BSD TCP leads to data corruption (if you don't use OOBINLINE option). [Bug in the sender] 2. Also, if 4.3 BSD TCP transmits (say) 3 segments and the third one had the URG flag set, and the first one got lost, then SND.UP gets messed up when the first segment is retransmitted. This, again, leads to data corruption. [Bug in the sender] 3. If segments containing urgent bytes have to be retransmitted, and get reassembled in the receivers TCP reassembly queue, data corruption could result [Bug in the receiver - Reassembly code] -Subbu