client-notes

网络端口的服务程序

Ideas for the client-side Linux driver:

A file /etc/rtty.conf looks like this:

/dev/rtty1    port-name   port.server.host.com:port     

or maybe like this:

Host = port.server.host.com:port

/dev/rtty1   port-name1
/dev/rtty2   port-name2
/dev/rtty3   port-name3
/dev/rtty4   port-name4

A user-mode program, rttysetup, runs as a daemon.  It reads
this file and opens a socket to the specified host and port.
It then opens the local rttyX device and passes the socket's
file description and the remote port name to the rtty driver
via an ioctl.

After doing this, it monitors all the sockets (via select()
I guess) watching for any sockets that are unexpectedly
closed.  If that happens, it re-opens the socket and passes
the new fd to the driver.

Before doing a read or a write on the socket fd, the rtty
driver should check if it is still valid.  If it isn't, it
simply returns a error on the active read or write from
user-land.  Eventually, it will be given a new fd by rttysetup.

The user-land application using the rttyX device should treat the
failed read or write as a re-tryable error, just like a glitch
on a serial cable.  Of course, it will have no way of knowing how
much data actually got through to the remote serial device, if a
write was in progress at the time of the link failure.

rttysetup should set its sockets to non-blocking during the
connect() to allow overlapping connect()s, thus avoiding
delays if a server host is down.  The socket should be set
back to blocking before passing the fd to the driver.


===================================================================

Another idea, which is used by the termpkg (termnet and termnetd)
suite (which does the same thing as portserver, but uses the
Telnet protocol as the foundation) is as follows:

   A daemon running on the client creates pty devices.  A
   config file defines which PTY is connected to which port
   on a portserver machine.  Client programs connect to the
   other side of the PTYs and treat them as read PTYs.  When
   the daemon is notified of ioctl()s that change terminal
   settings, it generates the correct RTERM commands and 
   passes them to the server.

The major advantage of this is that it's all user-land.