DNET V1.01 Alpha, BSD4.3 end. 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 Remember, this is an ALPHA release. CLEAN -shell script to clean up object files MAKE -shell script to make in client, dnet, server, and test bin -holds binaries, add this directory to your path client -holds client utilities sources dnet -holds dnet driver source doc -HOLDS FURTHER DOCUMENTATION. ALSO SEE THE SOURCE AND HEADER FILES! lib -holds the support library for client and server source. server -holds server utilities sources test -used to test DNET entirely on the system (i.e. run both ends of the driver in different directories). holds source to test program initiator. PREDEFINED VARIABLES: The enviroment variables DNETDIR is normally set to a directory which you should create for the rendezvous UNIX level sockets. If set you can run dnet, all servers, and all clients from any directory and they will setup their UNIX sockets in the right place. This variable should have a hanging slash on it ex: ~/.DNET/ 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. All the servers are UNIX domain sockets in DNETDIR (if the enviroment variable DNETDIR is not defined, then in whatever directory they were run from). The name of the socket in the directory is .DNET.# where # is the port number in decimal. DNET itself creates a socket called DNET.PORT . BASIC THEORY, AMIGA END: The communications protocol, obviously, is the same. In fact, it is completely symetrical (there is no such things as master/slave here). The DNET driver on the Amiga opens the serial port with the default preferences (or current modes if you have a terminal program active at the time you run DNET). Servers on the Amiga create public message ports named DNET.PORT.#, while the driver creates DNET.PORT . (look at the Amiga support library dnetlib.c to see how the interface works). GETTING IT RUNNING TO YOUR AMIGA: (MUCH DIFFERENT FROM V1.00) Before you can use DNET you must ensure that a valid PATH is setup on the Amiga side to DNET's binaries. You must modify the .login on the UNIX side and add the DNETDIR enviroment variable as specified above, and must ensure that your UNIX path is setup to point to associated binaries on the UNIX side. DNET WILL PROPERLY SET THE PARITY/DATABITS/PROTOCOL. YOUR PREFERENCES SHOULD CONTAIN THE CORRECT BAUD RATE AS THERE IS NO PROVISION TO CHANGE IT AT THE MOMENT. (1) RUN DNET. You will get a small terminal window set at 7 bits even parity. This is a dinky thing and is only meant to allow you to log in and startup the server on the remote end. CLOSE WINDOW: quit's DNET. MENU BUTTON: START's DNET ^C (BREAK CLI#): Abort DNET protocol and go back to DNET terminal window (2) dialup and log into your 4.2/3 UNIX system (3) start any servers on the UNIX system 's_shell &;s_copy &' NOTE: You do not need to start any servers to use FTERM. NOTE: Servers may still be active from your last session. (4) start dnet on the UNIX system with 'dnet' The terminal window should automatically go away. DNET is now running. An FTERM is automatically RUN (assuming your path is setup properly). You can also execute other various client programs, such as more FTERMs, TERMs, and PUTFILES from your Amiga (assuming you started the servers on the UNIX end).. you can start the servers on the UNIX end from your TERM/FTERM windows also. You can also startup servers on the Amiga end. Specifically, by doing a 'RUN S_COPY', you can then do a PUTFILES from the UNIX end to send things to your Amiga. AUTO RESTART FEATURE: At any time, if one end of the connection goes away (you quit DNET, for instance), you can RESTART the connection by restarting the driver that died. (I.E. you don't have to hangup, log back in, and start from scratch). KILL FEATURE: Not completely debugged, but theoretically if, say, the UNIX end goes away, you can BREAK the DNET on the Amiga side and it *should* EOF all active clients... causing them to abort. NOTE: The destination directory that PUTFILES files go to on the remote host is the one you were in when you started the server. This applies to any server you start, whether on the amiga or the UNIX host. I suggest you make a special directory and start the S_COPY server in that. NOTE: Closing all active clients does NOT kill DNET... you must BREAK it and hit the CLOSE gadget in it's window. *** UNIX SERVERS ACCESSED FROM AMIGA CLIENTS *** S_COPY: File transfer server. When running on the UNIX end, you can then use the PUTFILES command on the Amiga end to send files or ENTIRE DIRECTORY STURCTURES from the Amiga to the UNIX host. S_SHELL: Rlogin server. When running on the UNIX end, you can then use the TERM command on the Amiga end to start up a new login window. NOTE: These windows do not automatically adjust the tty rows and columns. (internal): FAST CSH server. This is an internal server in DNET. You use the FTERM command on the Amiga end to start up a new shell window. Response is much better as data flow s going through one less process. NOTE: These windows will AUTOMATICALLY adjust the tty rows and columns when you resize the window. The disadvantage is that they run on unnamed PTY's, and thus do not show up on 'who' *** AMIGA SERVERS ACCESSED BY UNIX CLIENTS:*** S_COPY: File Transfer server. When running on the Amiga, you can use the PUTFILES command on the UNIX end to transfer files or entire directory structures from your UNIX account to your Amiga. S_SHELL: Access a CLI from the UNIX end. use 'DSOC 8196' from the UNIX end to connect. This requires two things. (1) My PIPE: device must be mounted, and (2) a NEWCLI must be run on the PIPE: as follows: NEWCLI NIL: pipe:shell/t scriptfile KILLING DNET ON THE UNIX END WITHOUT HANGING UP: The Utility program QUITDNET will talk to the local DNET which will send a message to the DNET running on your UNIX system causing it to quit. You can tell it quit by looking at the Rx/Tx L.E.Ds on your modem ... when the UNIX system starts echoing character's normally. Then, close all client sessions, BREAK the DNET on your Amiga, and quit DNET by hitting the close gadget on the DNET window. DNET will never "give up"... it will continue retrying forever or until you ^C it. Restoration Sequence... logging off, hanging up. (1) Ensure all connections are closed and DNET is idle (2) BREAK (^C) DNET and all servers... they should all exit. (3) hangup the phone (2) can be swapped with (3) close DNET's window. Any servers left on the UNIX system will still be running and available next time you log on. 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 on 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). 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. TODO: -Too Much Buffer Copying