🚀 go-pugleaf

csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:

>In article <CMM.0.88.665054845.jon@gode.ifi.uio.no> 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:	<S=husemann;OU=informatik;P=uni-erlangen;A=dbp;C=de>
RFC822:	Dirk.Husemann@immd4.informatik.uni-erlangen.de