geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (08/09/89)
One of the questions I am often asked about PC-NFS is "how come there's no way for me to find out when a particular file server is going down? Unix users get notified." I point out that (at least on SunOS) the mechanism used is "rwall", which is an RPC service, and that for size reasons we can't afford to embed a version of rpc.rwalld in PC-NFS. This explanation is reasonable, but unsatisfactory. My reaction was to say "let's ask the NIC for a UDP port so that we can use it to send unsolicited messages to PCs running PC-NFS." That would certainly do the trick. However, a moment's thought reveals that the problem is bigger than just PC-NFS. Surprisingly, there is at present no simple ubiquitous message protocol to fulfil this function. rwall is fine for SunOS and other ONC licensees, but what about other systems? Do I have to rely upon SMTP? That's incompatible with the idea of broadcasting a simple message such as "The backbone will be down for five minutes at 12:00 to replace a bridge." This could be trivially simple or slightly more involved (but still simple). The trivial approach is to dedicate a UDP port for unsolicited system messages. Anyone could send one, in a single datagram, and the listener process would be responsible for delivering it as seemed appropriate for the system (dialog box, console message, etc.) A more complete approach would be to define a formal protocol so that it would be possible to convey information about the coding of the message, message length (so that TCP could be used instead) and so forth. [If the spec exceeds one page, it's too complicated.] Comments? Geoff Geoff Arnold, Internet: geoff@East.Sun.COM PCDS Group, Sun Microsystems Inc. --------------------------------------------------------------------------- Just think: If Unix had been developed in England, we'd all be using BCPL...
schwartz@shire.cs.psu.edu (Scott Schwartz) (08/09/89)
In article <681@east.East.Sun.COM> Geoff Arnold writes: | However, a moment's thought | reveals that the problem is bigger than just PC-NFS. Surprisingly, | there is at present no simple ubiquitous message protocol to fulfil this | function. | Comments? Zephyr, free from MIT, solves this one. -- Scott Schwartz <schwartz@shire.cs.psu.edu>
geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (08/09/89)
In article <SCHWARTZ.89Aug9000335@shire.cs.psu.edu> schwartz@shire.cs.psu.edu (Scott Schwartz) writes: > >In article <681@east.East.Sun.COM> Geoff Arnold writes: >| However, a moment's thought >| reveals that the problem is bigger than just PC-NFS. Surprisingly, >| there is at present no simple ubiquitous message protocol to fulfil this >| function. > >| Comments? > >Zephyr, free from MIT, solves this one. >Scott Schwartz <schwartz@shire.cs.psu.edu> I'll go back and check this out - my memory is that it was still a bit more complex that I'd like to see. Anyway, is anyone working to get an RFC out and push for "recommended" or "required" status for the protocol? Geoff Arnold, Internet: geoff@East.Sun.COM PCDS Group, Sun Microsystems Inc. --------------------------------------------------------------------------- Just think: If Unix had been developed in England, we'd all be using BCPL...
craig@NNSC.NSF.NET (Craig Partridge) (08/10/89)
Geoff: > Anyway, is anyone working to > get an RFC out and push for "recommended" or "required" status > for the protocol? I'm not aware of any efforts. If you are seriously interested in seeing this done, I suggest you contact Phill Gross (pgross@nri.reston.va.us). As head of the Internet Engineering Task Force, this sort of activity is his responsibility. Note that the IETF recently has been restructured to make it easier to get such RFCs written, issued and blessed -- for something like this, it could be only a few months. The next IETF meeting is in Hawaii (in part to see what Torben Nielsen's been doing in promoting IP in the Pacific Rim) at the end of October. Craig
beame@maccs.dcss.mcmaster.ca (Carl Beame) (08/11/89)
In article <681@east.East.Sun.COM> geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes: >One of the questions I am often asked about PC-NFS is "how come >there's no way for me to find out when a particular file server >is going down? Unix users get notified." I point out that (at least >on SunOS) the mechanism used is "rwall", which is an RPC service, and that >for size reasons we can't afford to embed a version of rpc.rwalld in >PC-NFS. This explanation is reasonable, but unsatisfactory. > > >Comments? > Since we implemented a rwalld in our BWNFS (PC based NFS client), I checked to see how much memory it takes. Not counting the initialization code, (which is not resident in memory), it takes 192 (decimal) bytes. But I guess if you write in C it takes a lot more :-) - Carl Beame Beame@McMaster.CA P.S: Geoff, does the new PC-NFS come with a fixed version of rpc.lockd for Sun OS4.0.1 ?
geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (08/11/89)
In article <1989Aug10.170537.1823@maccs.dcss.mcmaster.ca> beame@maccs.dcss.mcmaster.ca (Carl Beame) writes: >Since we implemented a rwalld in our BWNFS (PC based NFS client), I checked >to see how much memory it takes. Not counting the initialization code, (which >is not resident in memory), it takes 192 (decimal) bytes. I presume you're not including the portmapper in this total? We don't run a portmapper in PC-NFS, since we don't normally run any RPC based servers on the PC. (After all, we don't want to undercut our workstation business :^) "rwall" uses a pmap_rmtcall to contact rpc.rwalld, but to be correct you have to handle both direct and indirect calls, don't you? Also, are you doing the any duplicate filtering? >But I guess if you write in C it takes a lot more :-) I'm sure you know that none of the resident PC-NFS code is written in C... Geoff Arnold, Internet: geoff@East.Sun.COM PCDS Group, Sun Microsystems Inc. --------------------------------------------------------------------------- Just think: If Unix had been developed in England, we'd all be using BCPL...
jkp@cs.HUT.FI (Jyrki Kuoppala) (08/12/89)
In article <681@east.East.Sun.COM>, geoff@hinode (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes: >My reaction was to say "let's ask the NIC for a UDP port so that >we can use it to send unsolicited messages to PCs running PC-NFS." >That would certainly do the trick. However, a moment's thought >reveals that the problem is bigger than just PC-NFS. Surprisingly, >there is at present no simple ubiquitous message protocol to fulfil this >function. rwall is fine for SunOS and other ONC licensees, but >what about other systems? Do I have to rely upon SMTP? That's >incompatible with the idea of broadcasting a simple message >such as "The backbone will be down for five minutes at 12:00 >to replace a bridge." Not exactly what you need, but to get experience with SunRPC, I wrote a program called `rmsg' which can be used to send short (a few lines) messages to users on other machines. The program works quite like the bitnet send / tell feature, except that it directly contacts the remote machine with tcp/ip instead of using user-mode links as it's done on bitnet. Rmsg is available for anonymous ftp on sauna.hut.fi (128.214.3.119) in the directory pub/tcpip. Due to disk malfunctioning, anon ftp is not in use currently, but hopefully will be again in a few days. I haven't yet looked at zephyr, but I suppose it has more features and solves the problem of inter-user communications well. However, rmsg might be simpler to install. I hope it's useful to someone; we've been using it locally for some time, and it's nice because it's not as much a hassle as a full-screen application like talk is. Enjoy, //Jyrki Here's a README file from rmsg: This directory contains a messaging system which can be used to send write-like messages to logged-on users. The system can cross machine boundaries, so if another machine has the rmsgd program running, you can send messages to users on it. The system also allows bitnet virtual machine-like 'virtual users' to whom any user can send messages and they can answer the messages. The rmsgd server makes this possible by allowing a command 'exec' in a users .msgconf file, and whenever the user receives a message this command is executed and the message is piped to it. It is also possible to log incoming and outgoing messages and resend previous sent message. You can specify a file to which the last (or every) incoming message will be stored. Using the programs: ------------------- Rmsgd: Rmsgd is the server program for the system. It should be started by root, but for now it works even if started by ordinary users, even though some capabilities are disabled for security reasons (that is, exec and logging of incoming messages, since that would be done by the user-id who started rmsgd and not the receiver). At any time, there should be only one rmsgd running. It doesn't do any harm to have several rmsgds other than the newly-started servers unmap the previous and thus the previous servers are unusable. The server should be named 'rmsgd' to have it start as a daemon. Rmsg: Rmsg is the client end of the system. Rmsg is used by ordinary users to send messages. For example, rmsg foo@bar hello there ! ^D would send a message 'hello there !' to user foo at machine bar. By default, rmsg stores the last outgoing message in the user's home directory in the file .msgout. Then msg -r user@machine can be used to resend the message. Message is normally read from standard input until EOF. Configuration: -------------- The messages system has many options which the user can set by making a file '.msgconf' in her home directory and placing various command in it. Read the manual page for rmsg for more information. -- Jyrki Kuoppala Helsinki University of Technology, Finland. Internet : jkp@cs.hut.fi [128.214.3.119] BITNET : jkp@fingate.bitnet Gravity is a myth, the Earth sucks!
beame@maccs.dcss.mcmaster.ca (Carl Beame) (08/13/89)
In article <693@east.East.Sun.COM> geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes: > >I presume you're not including the portmapper in this total? We don't >run a portmapper in PC-NFS, since we don't normally run any RPC based servers >on the PC. (After all, we don't want to undercut our workstation >business :^) "rwall" uses a pmap_rmtcall to contact rpc.rwalld, but >to be correct you have to handle both direct and indirect calls, don't >you? We didn't implement the portmapper in total, we have a port 111 interrupt routine which checks for pmap_rmtcall to rwalld. The 179 bytes refers to all code (including portmapper check routine) which is resident and executed above the UDP level. > >Also, are you doing the any duplicate filtering? > No. > >I'm sure you know that none of the resident PC-NFS code is written in C... > No I didn't know that. - Carl Beame Beame@McMaster.CA