Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!ira.uka.de!fauern!faui43.informatik.uni-erlangen.de!dkhusema From: dkhusema@immd4.informatik.uni-erlangen.de (Dirk Husemann) Newsgroups: comp.protocols.iso Subject: Re: X.25 collisions Message-ID: <1991Feb1.095514.7003@informatik.uni-erlangen.de> Date: 1 Feb 91 09:55:14 GMT References: <143094@pyramid.pyramid.com> Organization: CS Department of the University of Erlangen-Nuremberg, West Germany Lines: 42 csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >In article jon@ifi.uio.no (Jon lnes) writes: >>In this case one DTE is required to act as a DCE for channel number >>allocation - which one is determined from the RESTART procedure. >Also note that this procedure is found exclusively in ISO8882; X.25(1984) does >not consider DTE-DTE operation at all. And, according to ISO 8208 Addendum 3, >this procedure is optional. I don't like it for the reason Jon mentioned: in >the case of Restart collision (which for most equipment happens every time >frame level is established), you can theoretically get into a race. ISO says Theoretically, okay, but I think it should be possible to make that time delay random enough, to get that procedure working. >to use a "randomly chosen time delay" for retransmitting the Restart. Random?! >Sure.... Better to just hard-configure one of the DTEs as a DCE. And in fact, - well, I think that just works fine as long as you stay inside your local net (IEEE 802 net, e.g.), yet - IMHO - difficulties arise, once your DTE starts communicating with a DTE on a net not administrated by yourself (e.g. your DTE is on a IEEE 802.3 net, the call leaves this net via a level 2 router - not an IWU - enters another remote net via an level 2 router there. Assuming that this remote net is under different administration, it may very well be the case that both of the DTEs are `hard-wired' to play DTE - what now?). Also, I assume that we don't want to restrict communication between LAN X.25 stations to matching DTE-DCE-pairs. How do you propose to solve the problem of two LAN stations within your local LAN both playing DTE (or DCE, in this case it doesn't matter) trying to communicate? I guess the solution as suggested by ISO 8208 is a possible solution to this problem. >ISO recommends this as preferable, in fine print after the specification for >the auto-selecting Restart procedure. I think it just mentions that under certain circumstances it might be the case that this procedure needn't to be supported. At least I couldn't extract any preferences from the text ... >(Actually, the ISO "X.25" documents contain a number of extensions like this >that just aren't a very good idea. Setting T1 on REJ frames, for example.) As I said it is a far better idea than to `hard-wire' it (I don't like the expression `hard-wired', it associates soldering and such stuff 8=) Dirk Husemann X.400: RFC822: Dirk.Husemann@immd4.informatik.uni-erlangen.de