home *** CD-ROM | disk | FTP | other *** search
-
- DNET V1.20
-
- DNET (c)Copyright 1987 Matthew Dillon, All Rights Reserved
-
- Matthew Dillon
- 891 Regal Rd
- Berkeley, Ca. 94708
-
- ...!ihnp4!ucbvax!dillon USENET
- dillon@ucbvax.Berkeley.edu ARPANET
-
- forum: ...!ihnp4!ucbvax!cory!dnet
- dnet%cory@ucbvax.berkeley.edu
-
- COMPILING, UNIX:
-
- Simply run the shell script MAKE.
-
- COMPILING, AMIGA:
-
- No compilation is needed, binaries are in the dnet.amiga/bin . To
- compile, you must have AZTEC C. You MUST make a precompiled
- symbol table file which contains all the subdirectory includes
- (see SYMBOLS.C in the INCLUDE directory). You need to assign
- comp: somewhere, make a directory 'include', and place the
- symbol table in that.
-
- As you will note looking at SYMBOLS.C, the precompiled symbol
- table MUST be made with the +L option.
-
- GETTING IT RUNNING:
-
- Setting it up on the UNIX system:
- (1) Make a directory (for example, ~/.DNET)
- (2) Modify your .cshrc , adding the following line:
- setenv DNETDIR ~/.DNET/
- (the hanging slash is essential)
- (3) All binaries are usually kept in dnet.unix/bin, add this
- directory to your path (in your .cshrc)
- (4) Place the file 'dnet.servers' in ~/.DNET . Modify the file
- according to your home directory and where you have put the
- servers.
-
- The file currently cannot handle ~ ... a FULL PATH IS REQUIRED.
-
- NOTE: You may want to chmod the directory 700 to disallow any
- unauthorized access to the network.
-
- Setting it up on the Amiga:
- (1) Set the proper baud rate in preferences. Bits and protocol do
- not have to be setup. Alternately, you can specify the
- baud rate on the command line (-bBAUD) when you run DNET.
-
- (2) DNET and the client programs must be available by your path.
- The servers (scopy sterm scli) may be placed anywhere.
-
- (3) The file dnet.servers must be placed in S:, and modified according
- to where you put the servers. DNET uses this file to auto-start
- servers.
-
- NOTE: The 'directory' field, currently holding 'ram:', is
- also currently not implemented. You should use the -d option
- with the UNIX end putfiles (see below)
-
- Starting it up:
- From your Amiga, RUN DNET. A terminal window will appear. Dialup
- and login to your UNIX account. Use an Amiga termcap ('sun' and
- 'ansi' also work).
-
- From your UNIX prompt type 'dnet', thereby starting DNET on the
- UNIX end. The DNET on the Amiga end should detect this, close the
- DNET terminal window, and automatically startup an FTERM.
-
- DNET is now running.
-
- You may then experiment around with multiple FTERM's, PUTFILES,
- etc... (see below for command format).
-
- NOTE: The Menu options in the original DNET window are used
- (1) to restart DNET if the remote end is already running,
- (2) to send a BREAK over the serial line
- (3) to exit DNET (same as the close gadget).
-
-
- KILLING DNET:
- If you currently have a good connection, you should be able to
- close all currently active client programs.
-
- It will now appear that everything is closed down. However, DNET
- is still running in the background (and you can even startup
- various client programs again).
-
- 1> quitdnet
-
- This will send a packet to DNET causing the remote end (the UNIX
- end) to quit. Wait two or three seconds, then
-
- 1> BREAK 2
-
- Where '2' is the CLI you ran DNET under originally. It may not
- be a '2'. This should cause DNET's window to come up again, and
- since the DNET on the UNIX end has exited, you should have a
- UNIX prompt again.
-
- NOTE: If you have not closed all clients, they will exit at this
- point (though not as nicely). Always wait for all clients to exit
- before closing DNET.
-
- At this point you may close the DNET window to kill dnet.
-
- ------------
- Alternately, you may simply hangup the modem, BREAK dnet, and
- close the DNET-Terminal window. Be sure to close all active
- clients before doing so. The only processes that will be
- left running on the UNIX system will be any servers that were
- started up. These take 0 cpu and very little swap.
-
-
- SERVERS
-
- Servers are started on demand on both ends. The Amiga end will kill
- any servers that were started when you close DNET. The UNIX end
- will leave any servers idle in the background when you kill DNET
- or hangup. These servers will be available the next time you log
- in.
-
- To kill servers on the UNIX end, you must kill the process id.
- 'ps x' will give you all processes running under your uid. A
- simple 'kill pid' should do it.
-
-
- BASIC THEORY, UNIX END:
- The DNET driver accepts connections from clients over UNIX domain
- sockets. It multiplexes and packetizes the data, sends it to
- whatever is on descriptor 0 (usually your tty). It receives data
- from the serial port, de-packetizes it, demuxes it, and sends it to
- the proper client. Additionaly, it receives open requests from
- the remote end and tries to connect to the proper server, starting
- the server if necessary.
-
- All the servers are UNIX domain sockets placed in the directory
- specified by the enviroment variable DNETDIR (if the enviroment
- variable DNETDIR is not defined, then in whatever directory they
- were run from). The path specification in this enviroment
- variable must have a hanging slash.
-
- BASIC THEORY, AMIGA END:
- The communications protocol, obviously, is the same. In fact, it is
- completely symetrical (there is no master/slave relationship
- in this protocol).
-
- The DNET driver on the Amiga usually opens the serial port with the
- default preferences (or current modes if you have a terminal
- program active at the time you run DNET).
-
- public message ports are used to send messages back and forth. The
- DNET driver on the Amiga end will allocate memory as needed to hold
- incomming data. FLOW CONTROL IS NOT IMPLEMENTED.
-
-
- CLIENT PROGRAMS AND ASSOCIATED SERVERS:
-
- SERVERS CLIENT PROGRAMS
- PORT UNIX AMIGA UNIX AMIGA
- ---- --------------- --------------------------
-
- 8192 SCOPY SCOPY PUTFILES PUTFILES
- 8193 SSHELL - - FTERM 8193
- 8194 - - - -
- 8195 (1) STERM DRAW 8195 FTERM
- 8196 - SCLI DSOC 8196 -
- 8197 SLOADAV - - LOADAV
-
- (1) This servers is implemented internally.
-
- AMIGA SERVERS:
-
- STERM -'talk' window.
-
- Brings up a talk window. You can talk with whoever is on
- the other end (an FTERM if the other end is another Amiga,
- or a DRAW 8195 if the other end is a UNIX machine).
-
- SCLI -remote shell unix->amiga. NOTE1: My PIPE: device must exist
- for this to work. NOTE2: Only works properly if you are at
- a CLI prompt when you exit (^C). NOTE3: Currently a hack.
-
- Currently can handle only one connection at a time.
-
- SCOPY -File copy server. Receives files and directory structures
- from the remote client and places them in the specified
- directory. If no directory specified by the remote client,
- they are placed in DF0: . Currently can handle only one
- connection at a time.
-
- UNIX SERVERS:
-
- SCOPY -same as Amiga server, but for Amiga->UNIX transfers. However,
- the UNIX version can handle multiple connections (multiple
- putfiles from the Amiga end).
-
- SSHELL -shell server, for use with the FTERM program on the Amiga
- end (when qualified by port 8193). This is the same as FTERM's
- default port, but automatically exec'd an 'rlogin localhost'
- in the terminal window yielding a named shell.
-
- SLOADAV -Load average server, for use the LOADAV on the Amiga end.
- The program 'la' must exist on the UNIX end.
-
-
- CLIENT PROGRAMS:
-
- (unix) DRAW port#
-
- Put terminal in RAW mode and connect to the specified port.
- The remote end must recognize some way of sending an EOF
- (STERM recognizes a ^C, for instance) because only the remote
- end can close the connection.
-
- (unix) DSOC port#
-
- Leave terminal in cooked mode and connect to the specified
- port #. This has the advantage that ^C's will kill the DSOC.
- Additionaly, you have input-editing. Used mainly with remote
- shells.
-
- (unix/amiga) PUTFILES [-ddirectory] file/dir file/dir file/dir ....
-
- Send one or more files or directories to the remote host, placing
- them in the directory specified by the -d command. If no -d
- is specified, DF0: is used (amiga server). The UNIX server uses
- the directory specified in dnet.servers on the UNIX end as a
- default.
-
- Currently, no file compression is done.
-
- (amiga) TERM [port#]
-
- OBSOLETE
-
- (amiga) FTERM [port#]
-
- Used to connect to a pty/shell on the UNIX end. This is faster
- than TERM (one less process to go through).
-
- (amiga) LOADAV [seconds/sample]
-
- Connect to the remote SLOADAV server on the UNIX system, and
- display the load graphically. Updates occur every 60 seconds,
- or in the time specified by the argument.
-
- (amiga) QUITDNET
-
- First close any active clients (terminal windows, loadav windows,
- etc....). Ensure the remote end is not connected to any local
- servers.
-
- Cause the DNET on the UNIX end to quit. You then BREAK the DNET
- on the Amiga end, getting a terminal window. You can then close
- the window and thus quit out of DNET on the local end.
-
-
-
- QUICKIE DESCRIPTION OF LOW LEVEL PACKET THEORY:
-
- DNET uses a windowed-packet scheme, as in transmission windows... up
- to 4 packets can be sent before one of them is acked. Each packet is fully
- checked with three check bytes (one for the header, and two for the data).
- If a packet fails it is ignored. If the receiver detects a missing packet
- it requests it be resent. If the sender doesn't get an ack within a given
- timeout it sends a CHECK packet, which asks the receiver if it got it or
- not (rather than just resend the packet, which might take a while).
-
- Taking the possibilities of long freeze times on the UNIX end due
- to high load factor, the UNIX DNET will play catch up if it receives
- multiple CHECK packets for the same window, responding only to the last one
- received.
-
- The channel multiplexing is embedded in the packet data... that is,
- you might have the data for several channels in a single packet, so
- maximum throughput is maintained even when you have a lot of little things
- going on.
-
- The packet protocol can handle up to 65535 channels. The actual
- implementation can only handle 128 handles, and is further limited by the
- number of file descriptors available on the UNIX side. This is usually
- around 64, or approximately 60 connections.
-
- -Matt
-
-
-