[net.dcom] bisync

mac@uvacs.UUCP (01/11/84)

I agree with (fortune.2005) and others that BiSync is a poorly specified
disaster.  The different levels of a protocol are all mashed into one big
spec, which has never been written down.  For example, transmission block
boundaries are significant to the customer.  Acks are numbered, but not
messages, so the loss of certain control messages can hopelessly foul up
the error recovery.  The stations are asymmetric, the difference being in
the waits on an idle line.  The difference is on the order of a second,
which AT&T threatened to introduce by using satellite links for leased
lines.  Face it, we've learned a little about communications protocols in
the past ~15 years.

The only virtue of BiSync is its near-universal availability.  We used it
to make a DTSS (Honeywell) mainframe appear as a RJE station to COMTEN
front ends on a Amdahl 470 running some IBM system, as well as to allow
Wang mincomputers to appear as terminals to DTSS.  The drawback is that all
parties involved had different ideas of the protocol.  Furthermore, there
are many flavors: 2780; 3780; 327n, with or without transparent text, block
transparency, ad nauseum.

We also ran into trouble with differences between X.25 networks
({Tele,Tym,Uni}Net,{Trans,Data}Pac, etc.) but nowhere near as messy.

Alex Colvin

 ARPA: mac.uvacs@csnet-relay CS: mac@virginia USE: ...uvacs!mac