1
When handler times out a node, he needs to return all the packets (especially
for open) that he has pending to the processes attempting to use the handler.
Failing to do so results in hung opens if the open is pending when the server
goes down.
2
can't start the handler before starting the server!
3
don't put NET-INET.library into libs: -- run the handler
watch the handler not work -- wish for an error message --
wish the handler would exit rather than put up a useless volume
4
"type net:pixie/ram:env/workbench" yields an enforcer hit from type then from
the handler -- "type work:txt:autodoc" behaves correctly
5
workbench copy drawer over net: (even an empty drawer) and visit unnamed
enforcer hits and the guru
6
copy * net:pixie/con...
reboot pixie
type some more
watch enforcer hits on your network-handler then
get "Error in writing - object not found"
and "destination file net:pixie/con/... removed"
7
copy * net:machine/con...
other guy closes his con window (by rebooting) before you close your
input, you send a line and... enforcer hit
8
server needs to strip out ".info" files (according to
MKS (via Toebes))  (file.c and lock.c), handler needs to not
worry about what kind of file anything is
9
cd net:coke/work doesn't
cd net:coke, cd work  does

(this is with 37.3 handler -- seems ok with my
37.4 debugging handler) (seems ok with 37.4 production)
 The number in the lock which indicates the correct device
 is somehow not getting copied.  This is in the RmtLock
 code.  I thought that I had fixed this too.
10
<work> cd net:pepsi
<pepsi> cd net:pepsi
<john>
Huh?
Similar problem (always with john) reported by Martin,
Spence, MKS

Investigation:
Probably from line 188 of volume.c (strcopy ses->name, "\x04John");)

 This is strange.  It means that the session needs to be initialized
 correctly.  This is one bug that needs serious investigation.

Further investigation:
When the handler connects to a server, it does so by calling SDNInitNode() and
then sending an ACTION_NETWORK_INIT packet to the server.  The
ACTION_NETWORK_INIT packet contains the name that the handler uses for the
server's machine.  If the server reboots while there is an open connection,
the next packets sent from the handler to the server alert the server that
something is wrong and it re-establishes the connection, apparently without
the handler ever knowing so.  Thus, the fresh server never receives an
ACTION_NETWORK_INIT and reverts to calling itself "john."

At least for INet, but probably for all networks, machines should have only
one name, and can determine what to call themselves without hearing it from
the handler.  Servers should find out from the driver at SDNSerInit() what to
call themselves and, unless it servers some other purpose, ACTION_NETWORK_INIT
should be eliminated.
11
if handler gets a non-zero lock, it needs to strip off what's in front of the
colon and the colon (this makes assigns work)
12
(Note two "Work")
<Work:> dir net:sprite
     Work (dir)
     System2.0 (dir)
     RAM (dir)
     Work (dir)
  RAM.info                         System2.0.info
  Work.info

(Note two "Test" and two "Junk")
<Work:> dir net:workbench
     Junk (dir)
     Test (dir)
...
     Test (dir)
     Junk (dir)
  CON                              CON.info
  DEVS.info                        Junk.info
  Junk.info                        LIBS.info
  RAM.info                         Stuff.info
  SYS.info                         Test.info

Probable cause:  device and volume are same.  Work: is both a
device and a volume, as are Junk: and Test:.


"FIXED:"  now does not show two Work:, Junk: or Test:.  Will still show
icon for device and volume if the two have diffrent names.  Must still
account for removable media volumes, but this requires re-design.
13
From John Toebes:
from remote: dir net:server
reboot remote machine
from remote: dir net:server
	server hangs here

Problem seems to be incorrect UnLock in server volume.c, line 214.
 This one is indeed strange.  I suspect that a lock on NET: is getting
 put onto the chain.  This needs some debugging code to catch and
 diagnose the problem post-mortum
14
config files are fragile
workbench dir of net:sprite hangs (clock pointer) with __DEFAULT__ access file:
DEFAULT: INCLUDE
Password:
special: readonly assign ram:special

(at least on a machine with no directory ram:special)
15
"dir net:NonExistentNode" sometimes gives a dir of local node!

Seems like the first time you try always does (adding that node
to net:), but subsequent tries always fail with "Could not get information for
net:AnotherNonExistentNode"
16
executing do-peer a second time results in enforcer hits to server,
and allows multiple handlers (and multiple net volumes)!
17
if running only network-handler, dies a horrible death
on "dir net:LocalMachine"
18
Convert driver to use UDP and change interface to be datagram rather than
stream oriented.  Sometime after this is done and before release, need to get
an assigned port number.
19
Doesn't handle removable media -- devlist is only touched at
server initialization
20
Can't remove a handler from the system.  No good reason to let user
remove the net: volume since does not eat significant resources.  Should
probably comment out all shutdown code in both server and handler.
21
NetBufSize should be device-dependent
(see handler device.c)
22
should be renamed to something besides "net colon" and server and
handler names should reflect the change.

should have configuration stuff moved from devs:networks to
somewhere else
23
This works:
<Work:> type * >con:0/0/600/200/TestingConsole
test
This works:
<Work:> copy * con:0/0/600/200/TestingConsole
test
This works:
<Work:> copy * net:sprite/con/0/0/600/200/TestingConsole
test
This doesn't work:
<Work:> type * >net:sprite/con/0/0/600/200/TestingConsole
test

The problem is that it doesn't update the console window at the
end of every line, only when ctrl-\ is reached.  You can't see
this until you add /wait to the command.
 This is related to the interactive file handles.  It will cause the
 same problem regardless of NET: or separate volume implementation.
 This is why I commented that we need the interactive file handles
 to be supported.
24
<Work:inetsrc/src/net/server> echo "talking via net:" >net:pixie/speak
echo: unable to open redirection file
[mount speak: on pixie]
<Work:inetsrc/src/net/server> echo "talking via net:" >net:pixie/speak
echo: unable to open redirection file
<Work:inetsrc/src/net/server> echo "talking via net:" >net:pixie/speak
[hang]
==================================================
open net:sprite on the workbench.  double-click CON icon.  Get
a con window, then get an "Unable to open your tool 'CON'" requester.
==================================================
private packet support  (?)
 This is ANDY's domain.  We are STILL waiting for his
 proposal so that private packets can be made real.
 Without that you can't do anything.
==================================================
2.0 packet support
 Just work.  The hard one to deal with is the ExAll
 packets.  Many of the others are quite trivial.  I
 would wait on the notification until everything else
 is done.
===================================================
use LockDosList to generate DEVLIST rather than
Forbid(), Permit(), use maybe use NextDosEntry() instead
of walking the list myself.


TESTING:
===================================================
recovery from reboot
	during copy
	during read
	while cd is remote
===================================================
reliability (i.e. data integritty with dropped/corrupted
packets)
===================================================
copy one harddrive to another
===================================================
access of df0: when no volume mounted at server init
access of X: where X is a volume in server at init and in drive now
access of X: where X is a volume in server at init but not in drive now
====================================================
delete net:#? all
delete net:#?/#?
delete net:#?/#?/#?
====================================================
dir net:NonExistentNode
====================================================
copy x net:SomeMachine/#?
====================================================
try PRT: and PAR:
====================================================
memory loss?
====================================================
have a half dozen machines do various simultaneous accesses to one server

diskspeed 3.1 to local RAM: produces results in which four diskspeeds each get
from 1/2 to 1/5 the performance of one diskspeed (variance not by which
diskspeed but by which test item).

With more or less as-from-SAS NET:  two different machines diskspeeding
to a third's RAM: drive causes one diskspeed to pause until the other
completes (or damn close to it).
====================================================
what if devs:networks/access/__default__ does not exist?
=====================================================
create, copy move and delete workbench drawers
=====================================================
