ken@gvax.cs.cornell.edu (Ken Birman) (02/28/90)
>From sendai!rich@sharkey.cc.umich.edu Wed Feb 28 06:53:22 1990 >Subject: Out of curiosity... >Reply-To: rich@sendai.ann-arbor.mi.us >Status: R >what's the general strategy for building the client only code? Y'know >the one where protos is on some other machine. I'm very tempted to >take at least a quick stab at a mac port. I have a couple of obscure >ideas for which isis would be quite useful. The arrangement will be as follows, initially (we may improve on this later). The client will be linked with clib, i.e. we will need to be able to build clib on the machine in question and will need to support lightweight tasks and have access to some sort of message transport layer. In the near term, this will need to be UDP, but later we can substitute others. The client will start up by calling isis_remote("mother.cs.cornell.edu", port_no) instead of isis_init; mom should be a machine where isis is running and the port-no is the "bcast" port number in the sites file (NOT the normal client port number, which will be used for local-stuff only). If specified as 0, we will look this up in /etc/services. Mom will often be the NFS server in the case of diskless clients; they would be down if that machine crashes, anyhow... It will be possible to detect loss of connection to ISIS and reconnect at some other system, but a bit annoying to do so. The remote client will (for this first release, at any rate) see a slower response time on ISIS system calls but will see the same high performance for "bypass" multicasts as it would if it was local. To port to a new system like the Mac you would need to get clib ported and, if UDP isn't available, build a transport protocol to talk to the machine. We are thinking of doing an OS/2+NETBIOS port but aren't sure how we would finance it... Ken