Newsgroups: comp.protocols.tcp-ip Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!think.com!snorkelwacker.mit.edu!ira.uka.de!smurf!urlichs From: urlichs@smurf.sub.org (Matthias Urlichs) Subject: Re: Is there such a thing as a uucp daemon? Message-ID: Date: Thu, 20 Jun 1991 19:13:29 Organization: University of Karlsruhe, FRG References: <8295@auspex.auspex.com> <9106120113.AA16777@toaster.SFSU.EDU> <165451@felix.UUCP> Lines: 23 In comp.protocols.tcp-ip, article <165451@felix.UUCP>, darnold@felix.UUCP (Dave Arnold) writes: < In article <9106120113.AA16777@toaster.SFSU.EDU> eps@cs.SFSU.EDU writes: < >Will it interoperate with BSD uucpd? Not out of the box. For < >one, AT&T's code uses 'e' protocol rather than 't' protocol over < >TCP connections. < < But, what's to stop me from running 'g' over TCP connections? Nobody, assuming that you run it through a pty. Directly attaching stdin/out to uucico won't work because it wants to issue several ioctls which are only defined for terminals. This holds for "e" protocol if the vendor hasn't changed his copy; thererfore a direct connection between AT&T-UUCP and BSD-UUCP can't work.. Don't forget, however, that almost any protocol is more efficient than g when run over a TCP path, except possibly "x" which relies on empty packets and therefore won't work at all. -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330) \o)/