gert@seismo.CSS.GOV@uvabick.UUCP (02/18/87)
Path: uvabick!gert From: gert@uvabick.UUCP (Gert Hulstein) Newsgroups: comp.dcom.lans,mod.protocols Subject: Courier Remote Procedure Calls Keywords: Courier Networks Message-ID: <116@uvabick.UUCP> Date: 17 Feb 87 23:15:30 GMT Lines: 9 Hi, Is there any information available on the courier remote procedure calls ? If so, where can I get it ? Also, what implementations of courier do exist ? Gert Hulstein, Amsterdam University, The Netherlands. mcvax!gert@uvabick.uucp
mrs2@seismo.CSS.GOV@bunny.UUCP (02/19/87)
Path: bunny!mrs2 From: mrs2@bunny.UUCP (Mark Scherfling) Newsgroups: mod.protocols Subject: Re: Submission for mod-protocols Keywords: Courier, Xerox, XNS Message-ID: <927@bunny.UUCP> Date: 19 Feb 87 15:14:51 GMT References: <8702172315.AA00735@uvabick.UUCP> Reply-To: mrs2@bunny.UUCP (Mark Scherfling) Followup-To: Info on Courier Organization: GTE Laboratories, Waltham MA Lines: 26 The Courier Remote Procedure Call protocol (RPC) was developed by Xerox as part of their XNS protocol suite. Two years ago, they were selling documentation packets which contained all the Xerox protocols (currently published for external consumption) including the Interpress printing protocol. Below is the contact I had in ordering these manuals: Dennis Frahmann Manager, Protocols Marketing Xerox Corp. Office Systems Division 2100 Geng Rd. Palo Alto, California 94303 I am unsure of any commercial implementation of Courier. Network Research Corp.'s Fusion products may have implemented Courier, but I'm not sure. XNS has lost favor among the network integrators due to the need to communicate with government agencies (running TCP/IP), the overwheming availability of TCP/IP in Berkeley Unix implementations, and the incomplete (read: non existence) of common applications for XNS. Its too bad. Courier and Clearinghouse were some of the finest higher level protocols to exist when they were published. Bill Joy of Sun Microsystems liked them so much, he rewrote them for TCP/IP and called them RPC and YellowPages, respectfully. Oh well, protocols marchs forward. -- Mark Scherfling GTE Labs
news@seismo.CSS.GOV@sun.UUCP (02/20/87)
Path: sun!gorodish!guy From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: mod.protocols Subject: Re: Submission for mod-protocols Message-ID: <13682@sun.uucp> Date: 20 Feb 87 05:35:58 GMT References: <8702191514.AA20193@bunny.UUCP> Sender: news@sun.uucp Reply-To: guy@sun.UUCP (Guy Harris) Organization: Sun Microsystems, Mountain View Lines: 40 >Courier and Clearinghouse were some of the finest higher level >protocols to exist when they were published. Bill Joy of Sun Microsystems >liked them so much, he rewrote them for TCP/IP and called them RPC and >YellowPages, respectfully. Well, aside from the fact that: 1) Bill didn't write them single-handedly (for example, the manager of the NFS group here, and one of the developers of Sun RPC and RPC-based services, is Bob Lyon - yes, the same Bob Lyon listed as one of the authors of the clearinghouse at the end of Oppen and Dalal's TOOIS paper). 2) They weren't "rewritten for TCP/IP"; Sun RPC has an object-oriented interface to the underlying transport protocol (you provide an interface module to the transport in question - which need not be a network protocol, but could be something like shared memory - that provides a certain set of operations) and has been put on top of, e.g., the ISO connectionless transport protocol (and could probably be put on top of, e.g., SPP). Also, Courier performs the functions of RPC and XDR combined, not just RPC. 3) The Yellow Pages is a lower-level remote database access protocol than Clearinghouse. The ranges of the mappings it performs consist of uninterpreted data, not property lists. It does not support queries like Clearinghouse's "LookupGeneric", because it doesn't interpret those data; you can look up something by name, or you can get every entry in a map and do whatever kind of lookup you want, but you can't say "give me all the objects that match this wildcarded name and that have thus-and-such a property." It also has no mechanism for updating mappings. I guess this isn't *too* far off (other than the fact that the proper term is "respectively", not "respectfully"). If you only have a few widely-spaced data points, be careful when attempting interpolation; it looks pretty silly when you try to use linear interpolation on data points taken from a sine wave....
jqj@GVAX.CS.CORNELL.EDU.UUCP (02/21/87)
A request for information on Xerox Courier and publicly available implementations appeared recently on this news group. It should first be noted that very few compatible implementations of Courier and the Xerox applications protocols that use it exist. Most of the Xerox implementations (for XDE, ViewPoint, Cedar, and Interlisp) interoperate, but even there there are some incompatibilities. 3Com has an implementation which interoperates at the Courier level, but not at the applications level; for example, they use different Clearinghouse properties. Last I checked, Fusion's XNS protocol suite was Xerox-compatible at the SPP level but not at the Courier level. One non-commercial, but publicly available, implementation of the Courier protocols is the Cornell xnscourier suite distributed as part of the "user contributed" software for 4.3BSD. It is designed to interoperate with Xerox implementations, especially with the XDE implementation. The suite includes a stub compiler which takes descriptions in the Courier language and generates C client and server stubs, a fairly large runtime library for common dataconversion and applications problems (e.g. almost all Xerox uses of Courier require dynamic binding to a network address based on a Clearinghouse name, so the library includes routines that find a Clearinghouse, use it to translate from a string to network address, generate the appropriate authentication, etc.). Also, the library includes sample applications using some of the public Xerox protocols layered on Courier: remote terminal emulation client and server (GAP protocol), file transfer client (Filing protocol; a file transfer server is coming soon), printing client so you can send your Interpress masters to a Xerox printer, and so on. The package runs on 4.3BSD on VAXes and UTX 2.0 on Goulds. I have not tested it on SUNs, but believe that it would run there with little problem (requiring currently undistributed SUN XNS kernel support). For further information on the UNIX Courier package, send me mail. jqj@systems.cs.cornell.edu jqj@cornell.arpa cornell!jqj jqj@crnlcs.bitnet
alan@COLUMBIA.EDU.UUCP (02/24/87)
Path: columbia!alan From: alan@columbia.UUCP (Alan Crosswell) Newsgroups: mod.protocols,mod.computers.vax Subject: Need help with LAN Bridges Message-ID: <4373@columbia.UUCP> Date: 23 Feb 87 22:42:25 GMT Reply-To: alan@columbia.edu (Alan Crosswell) Organization: Columbia University CS Department Lines: 34 We have several LAN Bridges interconnecting departmental ethernets to our campus "backbone." We have recently noticed that a lot of traffic that should be filtered by the LAN Bridge is not being filtered; packets between a host on the backbone and another department are showing up on a second department's network. These are not broadcasts, they are things like tcp/telnet and tcp/ftp. Unfortunately, we do not have a VMS system or RBMS so I can't dump out the LAN Bridge's tables to see if that will provide any clueas to what it going on. My understanding was that the factory default would be to do all the right filtering so we wouldn't need RBMS for day-to-day stuff -- only for unusual situations..... I have also noticed the LAN Bridge for our department is transmitting a "LAN Bridge protocol" packet about once a second onto the departmental network. The LAN Bridge installation manual (the only documentation of the thing I have) says that the Bridges talk to each other when they boot so that they can see if there are any loops. Are they saying anything else to each other and can they possibly get confused if, for instance, some of them have the "A" port plugged into the backbone while others are plugged in with the "B" port? Any help and/or explanations of how LAN Bridges work or what might be wrong would be greatly appreciated! One of our departmental networks that just got connected to the backbone may have to disconnect -- the extra noise is wiping out their diskless SUN performance. Alan Crosswell Columbia University alan@columbia.edu (212) 280-3754
larry@pdn.UUCP.UUCP (03/02/87)
Path: pdn!larry
From: larry@pdn.UUCP (Larry Swift)
Newsgroups: mod.protocols
Subject: Re: OSI references & flow control
Message-ID: <665@pdn.UUCP>
Date: 2 Mar 87 16:50:14 GMT
Organization: Paradyne Corporation, Largo, Florida
Lines: 30
(In response to an email request for OSI reference material)
There's a good collection of articles and original work by Stallings,
"Computer Communications: Architectures, Protocols, and Standards", IEEE
Computer Society Press, 1985. (He's from MIT also, I believe.) The OSI
Ref. Model (ISO is 7498) itself is available from the American National
Standards Institute. A good seminar (and the material that goes with it,
if one can find it without taking the seminar) is available from Omnicom,
Inc, Vienna, Va. Omnicom's executive director, Hal Folts, has also
published "A Tutorial on the OSI Reference Model", 1982, which is probably
available from Omnicom. Other compendiums are readily available in works
such as Auerbach and Datapro's Data Communications. (I have no affiliation
with any of these people or organizations.) As I said, there are many others.
In locating these references for you, I discover that I may be somewhat out
of date in citing OSI's Layer five (Session Control) as that "where the data
path is finally narrowed to a single user", although I suppose it may still
be arguable. If sessions and transport connections are indeed tied
together in one-for-one relationships, then it would seem that Layer 4
is the upper limit of flow control mechanisms. (This seems to me to be in
conflict with the transport layer's responsiblity for cost-effective
conections.)
--------------------------------
Larry Swift
UUCP: {ihnp4,gatech,cbosgd}!akgua!usfvax2!pdn!larry
Snail mail: LF-207, Paradyne Corp., 8550 Ulmerton Road, Largo, FL, 33541
Phone: (813) 530-8605news@seismo.CSS.GOV@hafro.UUCP (03/03/87)
Path: hafro!gunnar From: gunnar@hafro.UUCP (Gunnar Stefansson) Newsgroups: mod.protocols Subject: X.25 software for Unix ? Message-ID: <334@hafro.UUCP> Date: 2 Mar 87 21:38:55 GMT Reply-To: gunnar@hafro.UUCP (Gunnar Stefansson) Distribution: world Organization: Marine Research Institute, Reykjavik Lines: 17 Does anyone know of software for handling the X.25 protocol on Unix machines ? In particular, we do not want to have to connect our machines to a PAD with n serial ports, which will then force us to use up n serial ports on the computer. Rather, the ports should be implemented in software as is done on several other systems, with just one physical connection going out of the machine, but several logical ones. We would be most interested in specific solutions for the HP 9000 series, but general information on solutions under Unix will also be appreciated. Thanks, Gunnar
larry@pdn.UUCP.UUCP (03/04/87)
Path: pdn!larry From: larry@pdn.UUCP (Larry Swift) Newsgroups: mod.protocols Subject: Re: OSI references and flow control Keywords: OSI flow control Message-ID: <669@pdn.UUCP> Date: 4 Mar 87 14:51:45 GMT Organization: Paradyne Corporation, Largo, Florida Lines: 40 (In reply to an email discussion) >specific references to how to do FLOW CONTROL in the OSI model. Peer-to-peer flow control, as you have indicated, is much discussed in OSI circles. I don't know of any references addressing flow control at the service interface, however (see below). If I find any, I'll let you know. >I suspect whoever defined the standard do not know how well their stuff works >in the real network. You might have a good point, there! > In OSI model, each layer determines its own flow control parameter > values. Now assume transport layer sends lots of data (it has a large > window size), but the net can't send that fast. Where are data buffered? > What problems does this cause? (in reality, not in definition. These > real problems are seen everyday.) You are referring to a resource problem in the service interface(s), which, I agree, the Model hasn't addressed at all, as of yet. One of the reasons, I'm sure, is that the problem is usually internal to the node rather than the network (ie, the given two layers are operating in the same program environment). I know from experience that this takes a rather sophisticated, communications-oriented operating system to resolve in a common manner, and therefore is subject to all sorts of non-networking requirements being imposed. Unix, for example, is a long way from being able to address the problems. I suspect the OSI Model won't be upgraded to address the problems for a long time either, since I don't believe the upper layers are yet locatable in separate program environments (ie, machines). -------------------------------- Larry Swift UUCP: {ihnp4,gatech,cbosgd}!akgua!usfvax2!pdn!larry Snail mail: LF-207, Paradyne Corp., 8550 Ulmerton Road, Largo, FL, 33541 Phone: (813) 530-8605
jim@seismo.CSS.GOV@cs.strath.ac.uk (Jim Reid) (03/05/87)
Path: strath-cs!jim From: jim@cs.strath.ac.uk (Jim Reid) Newsgroups: mod.protocols Subject: Re: Submission for mod-protocols Message-ID: <412@stracs.cs.strath.ac.uk> Date: 5 Mar 87 20:54:36 GMT References: <8703022138.AA29794@hafro.UUCP> Reply-To: jim@cs.strath.ac.uk Distribution: world Organization: Comp. Sci. Dept., Strathclyde Univ., Scotland. Lines: 30 In article <8703022138.AA29794@hafro.UUCP> gunnar@hafro.UUCP writes: >Does anyone know of software for handling the X.25 protocol on Unix >machines ? The University of British Columbia have added a CCITT socket domain to 4.[23] BSD UNIX to support an X.400 messaging system. It uses the sync. port of a DMF32 and I understand it should also work on a Sun with one of the RS232 ports configured for synchronous communication. Sun also sell X.25 for their SUNlink product: it also provides socket level communication (based on UBC code?) The SUNlink board has some intelligence and should manage a good bit of the X.25 processing. >We would be most interested in specific solutions for the HP 9000 >series, but general information on solutions under Unix will also be >appreciated. Well, in section 1m of our HP9000 manuals there is a getx25 command. This configures getty for reverse pad ports. The entry makes reference to a HP pad, but I don't know if this is a box or just another card that slots into the backplane. I'd guess this offloads X.25 and triple-X from UNIX entirely, so probably doesn't count. Jim ARPA: jim%cs.strath.ac.uk@ucl-cs.arpa, jim@cs.strath.ac.uk UUCP: jim@strath-cs.uucp, ...!seismo!mcvax!ukc!strath-cs!jim JANET: jim@uk.ac.strath.cs "JANET domain ordering is swapped around so's there'd be some use for rev(1)!"
stephen@seismo.CSS.GOV@comp.lancs.ac.uk ("Stephen J. Muir") (03/06/87)
Path: dcl-cs!stephen From: stephen@comp.lancs.ac.uk (Stephen J. Muir) Newsgroups: mod.protocols Subject: Re: X.25 for Unix 4.2bsd Message-ID: <274@dcl-csvax.comp.lancs.ac.uk> Date: 6 Mar 87 12:50:17 GMT References: <8703022138.AA29794@hafro.UUCP> <455*neufeld@ean.ubc.cdn> Reply-To: stephen@comp.lancs.ac.uk (Stephen J. Muir) Distribution: world Organization: Department of Computing at Lancaster University, UK. Lines: 14 In article <455*neufeld@ean.ubc.cdn> neufeld@mcvax.UUCP (Gerald Neufeld) writes: >We have developed X.25 for 4.2bsd Unix. The X.25 code uses the protocol <support within the unix kernel ... interfaced via sockets. It also includes >PAD support as a client within user process (there is a call out/in daemon). <The software requires a DMF-32 on a Vax (there is also a DUP-11 driver). It >also runs on a Sun. This sounds exactly the same as the code from the University of British Columbia. In what ways does it differ? -- EMAIL: stephen@comp.lancs.ac.uk | Post: University of Lancaster, UUCP: ...!mcvax!ukc!dcl-cs!stephen | Department of Computing, Phone: +44 524 65201 Ext. 4120 | Bailrigg, Lancaster, UK. Project:Alvey ECLIPSE Distribution | LA1 4YR
neufeld@mcvax.UUCP (Gerald Neufeld) (03/07/87)
When I mentioned that "We have developed X.25 for 4.2bsd Unix", I should have said "We, at the University of British Columbia, have ....". The code I mentioned at that of UBC is one and the same. Sorry for the omission.
tommy@ssds.UUCP (03/20/87)
Path: ssds!tommy From: tommy@ssds.UUCP (Tommy Phillips) Newsgroups: mod.protocols Subject: Sperry ISO Session Protocols -- Help Message-ID: <119@ssds.UUCP> Date: 17 Mar 87 22:24:34 GMT Sender: tommy@ssds.UUCP Reply-To: tommy@ssds.UUCP (Tommy Phillips) Distribution: usa Organization: SSDS, Inc., Littleton, CO Lines: 14 Keywords: Sperry Unisys ISO-OSI Summary: Looking for COTS product Does anyone out there know of any commercial ISO Session Layers running on Sperry (Unisys now, thanks to Burroughs) 1100/xx mainframes? We're looking for one, but so far no luck. PLEASE help if you have even a HINT of where to look. If you send me an inquiry and I get any hints I will share the results. I somehow suspect I'll be the only poor sucker looking for this stuff, though. Thanks in advance, Tommy Phillips SSDS Inc. ...hao!udenva!ssds!tommy
mrose@rutgers.UUCP.UUCP (03/21/87)
I don't know if this helps but:
-----
A N N O U N C E M E N T
The next release of the "ISO Development Environment at NRTC" will be
available on 23 March 1987. This release is called
ISODE 2.0
This software supports the development of certain kinds of ISO/CCITT/ECMA
protocols and applications. Here are the details:
- ISODE is not proprietary, but it is not in the public domain. This was
necessary to include a "hold harmless" clause in the release. The upshot
of all this is that anyone can get a copy of the release and do anything
they want with it, but no one takes any responsibility whatsoever for any
(mis)use.
- ISODE runs on native 4.2BSD and SVR2 with an Excelan card. It
also runs on a AT&T 3B2 running SVR2 and the WIN TCP/IP package,
native ROS (the Ridge Operating System), and HP-UX. (Future
releases will support VAX/VMS, PC-XENIX, and a variant of PC/IP.)
- Current modules include:
TSAP - ISO transport service (TP0 on top of TCP)
SSAP - ISO session service
PSAP - ASN.1 abstract syntax and transfer notation
PEPY - ASN.1 to internal datastructure facility
PSAP2 - ISO presentation service
AcSAP - ISO association control service
RtSAP - ISO/CCITT reliable transfer service
RoSAP - ISO/CCITT/ECMA remote operations service
- Although the ISODE is not "supported" per se, it does have a
problem-reporting address, Bug-ISODE@NRTC.NORTHROP.COM. Bug reports (and
fixes) are welcome by the way.
- The discussion group ISODE@NRTC.NORTHROP.COM is used as an open forum on
ISODE. Contact ISODE-Request@NRTC.NORTHROP.COM to be added to this list.
- The primary documentation for this release consists of a User's
Manual (approx 300 pages) and a set of UNIX manual pages. The
sources to the User's Manual are in LaTeX format. In addition,
there are a number of notes, papers, and presentations included in
the documentation set, again in either LaTeX or SLiTeX format.
For more information, contact:
Northrop Research and Technology Center
Attn: Automation Sciences Laboratory (0330/T30)
One Research Park
Palos Verdes Peninsula, CA 90274
USA
+1-213-544-5393
There are several ways to get a distribution:
- DARPA/NSF Internet
If you can FTP to the DARPA/NSF Internet, you can use anonymous FTP
to louie.udel.edu [10.0.0.96] and retrieve the file portal/isode-2.tar.
This is a 5MB tar image The file portal/isode-2.tar.Z is the tar
image after being run through the compress program (approx. 2MB).
- NIFTP
If you run NIFTP over the public X.25 or over JANET, and are
registered in the NRS at Salford, you can use NIFTP with username
guest, and your own name as password, to access UK.AC.UCL.CS to
retrieve the file <SRC>isode-2.tar. This is a 5MB tar image The
file <SRC>isode-2.tar.Z is the tar image after being run through the
compress program (approx. 2MB).
- NORTH AMERICA
For mailings in NORTH AMERICA, send a check or invoice for $130 US
dollars to:
Department of Electrical Engineering
Attn: Prof. David J. Farber
University of Delaware
Newark, DE 19716
USA
+1-302-451-1163
The tape will be written in tar format at 1600bpi. Do not send
tapes or envelopes. Documentation is separately available for $20
US dollars.
- EUROPE
For mailings in EUROPE, send a cheque or invoice for 100 pounds
sterling to:
Department of Computer Science
Attn: Soren Sorenson
University College
Gower Street
London, WC1E 6BT
UK
+44-1-387-7050 x3680
The tape will be written in tar format at 1600bpi, and returned with
a documentation set. Do not send tapes or envelopes. Documentation
only is the same price.