Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bloom-beacon!spdcc!xylogics!loverso
From: loverso@Xylogics.COM (John Robert LoVerso)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: rwhod protocol and >42 users
Message-ID: <7370@xenna.Xylogics.COM>
Date: 9 Oct 89 19:53:57 GMT
References: <1178@celit.fps.com>
Reply-To: loverso@Xylogics.COM (John Robert LoVerso)
Distribution: comp
Organization: Xylogics, Inc., Burlington MA
Lines: 48

In article <1178@celit.fps.com> dave@fps.com (Dave Smith) writes:
> Has there been any thought given to extending the rwhod protocol so that
> more than 42 (1024/sizeof whoent (==24)) users on a system will be reported 
> correctly?  This limit is entirely too small for today's systems.

Yes.  I played with this at Encore.  I did two approaches.  The
first one, based on a hack we had at SUNY/Buffalo, added a new
rwhod packet type that was just a continuation of the previous
information.  This allowed `n' packets; a modified rwhod would just
issue as many packets as needed.  Modified rwhod's would collect
these packets and concatinate them to the spool/rwho file.  Unmodified
rwhod's would just ignore the new packet types (except on certain
SystemV machines, where it would print stupid, obnoxious messages
on the console about `unknown type', sigh).  This worked.

The second approach just up'd the sendspace for udp packets to 8K;
this works with no protocol modification.  With this, fragmentation
happens automatically over networks with an MTU less than the packet
size.  However, several bugs in 4.2BSD prevents this from working.
4.3 is no problem.

With either approach, rwho/ruptime needed to be modified so that
they read more than 41 whoents from the spool/rwho file (i.e., just
read all of the file).

However, this is all BAD.  Either approach causes rwhod to send
out multiple broadcast packets.  On a relatively fast machine,
allowing IP to do the fragmentation, the broadcasts will hit the
net almost back-to-back.  This can cause many more problems then
benefits.  Many people will tell you that rwhod is ugly enough as
it is, just producing one broadcast packet every 1 [4.2] or 3 [4.3]
minutes.

If you are really hot on producing a new protocol, how about this.
Simple observation shows that most of the information rwhod gives
out doesn't change all that much.  So, perhaps a more reasonable
approach, would be to use a delta protocol, where any given packet
would include some new whoents and a few bits to delete old whoents.
Thus, over a period of time (10 minutes?), a rwhod-listener might
pick up a complete list of users.

Finally, you can just chuck rwhod and use Sun's "rusers/rup" instead.
It works, albeit not very well.

John
-- 
John Robert LoVerso			Xylogics, Inc.  617/272-8140
loverso@Xylogics.COM			Annex Terminal Server Development Group