Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!uhccux!munnari.oz.au!murtoa.cs.mu.oz.au!ditmela!yarra!cit5!jwb From: jwb@cit5.cit.oz (Jim Breen) Newsgroups: comp.dcom.lans Subject: Re: What services does X.25 provide? Summary: You forgot about the "D" bit Keywords: x.25, services, login, e-mail, file transfer, IPC Message-ID: <1989Sep18.020822.16329@cit5.cit.oz> Date: 18 Sep 89 02:08:22 GMT References: <796@maxim.erbe.se> <3279@wasatch.utah.edu> <522@wet.UUCP> <1167@virtech.UUCP> Organization: Chisholm Institute of Technology, Melb., Australia Lines: 30 In article <1167@virtech.UUCP>, dennis@virtech.UUCP (Dennis P. Bednar) writes: * * This is correct. X.25 is specified as a protocol between a DTE * (packet switching host) and a DCE (IMP or interface message * processor a.k.a. packet switching node). While X.25 level * 2 (the lowest protocol layer) has reliability built into it * (checksums, acks, retransmissions, sequenced packets), the * reliablility is only between the host and the IMP. There is no * guarantee of end-to-end reliablity between two hosts: * * (local) (local) (remote) (remote) * DTE DCE DCE DTE * host <---> IMP <---> IMP <----> host * * In other words, when the local DTE on the left sends * a level 3 DATA packet and receives a level 3 RR acknowledgement * packet from the local IMP (on the left side of the above * diagram), it only means that the local IMP has acked the * packet, but not necessarily that the remove DTE in the * right side of the figure has even received it. ..........[etc] Full 1984/1988 X.25 allows for the "D" bit in the Call Request and Data packets to request "Delivery Confirmation". When this option is available and used, RR packets advise successful receipt by the *remote* DTE, not the local DCE. -- _______ Jim Breen (jwb@cit5.cit.oz) Department of Robotics & /o\----\\ \O Digital Technology. Chisholm Inst. of Technology /RDT\ /|\ \/| -:O____/ PO Box 197 Caulfield East 3145 O-----O _/_\ /\ /\ (p) 03-573 2552 (fax) 572 1298