Xref: utzoo comp.protocols.misc:1043 comp.protocols.iso:1300 Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!mips!sgi!rpw3@rigden.wpd.sgi.com From: rpw3@rigden.wpd.sgi.com (Rob Warnock) Newsgroups: comp.protocols.misc,comp.protocols.iso Subject: Re: which protocols to use ?? Message-ID: <72625@sgi.sgi.com> Date: 19 Oct 90 04:27:15 GMT References: <11347@life.ai.mit.edu> Sender: guest@sgi.sgi.com Reply-To: rpw3@sgi.com (Rob Warnock) Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 39 In article <11347@life.ai.mit.edu> melnik@gnu.ai.mit.edu (Ofer Melnik) writes: +--------------- | A group of friends and I are in the process of creating an intelligent | data acquisition system... It consists of one master (an MSDOS machine) | and up to 256 slave terminals... The flow of communications is basiclly | polling; The master repeatedly polls each slave,... | As we see it asynchronous communications is the only viable form... | The first being obviously that we have no way to send a clock over the line. | | What protocols would you recomend for our applications?? Any infrmation | would be greatly appreciated. +--------------- I would recommend using DDCMP (the DEC link-level protocol) in polled multi-drop mode, with multi-drop modems. This is what we did some 15+ years ago at Digital Communcations Associates to interconnect our stat muxes when we had to use multi-drop lines. (Some of our customers were replacing existing multi-drop IBM terminals with our gear -- we could change the terminals but couldn't change the line or the modems.) DDCMP is fairly easy to implement, and can be done in a small amount of memory. (We did it in an 8K PDP-8, *including* the async drivers and stat-mux functions for multiple terminals/node.) It explicitly supports multi-drop, including letting the master bury an to one slave in a data packet to another (or something like that). If the systems are reasonably close, you can simulate multi-drop modems with a diode/resistor hack between the transmit line of each slave and the common line back to the master. (This is what we did in-house when testing.) -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311