For Unix systems, the solution Rob describes exists and is simple to use.
The 'term' package by Michael O'Reilly does pretty much what Rob
described. It took me a few hours to understand and modify XMosaic 1.2 to use
term, and less than an hour to modify 2.0pre6.
It's actually simpler than Rob's model: term works at the TCP level,
so you just intercept the TCP socket calls in the application and redirect
them to term. The application gets back a socket, which it then reads and
writes just as if it were connected directly. Term does compression and
error correction (and multiplexing of requests from multiple clients),
so it's quite reliable for a point-to-point link.
I would love to have the #ifdef'ed TERM code in 2.0 so I can save
that hour on each release. That would certainly be easier than
starting from scratch, for that 'volunteer' Rob is looking for.
Tony's idea of modifying the CERN server is interesting, but I have
no need to run any browser other than Mosaic, so modifying Mosaic
is simpler, and requires one fewer running process. But if the local
server could do local caching, I would probably start using it.
I would rather use PPP or SLIP, but the host machine I dial in to does
not offer those services. I pay $96/year flat rate for my account.
Accounts I found offering SLIP or PPP all charge more, plus they
have connect time charges. That adds up real fast for someone who
likes to browse the net a lot.
Term does not require any special packages to be installed on either
machine, and can be compiled and run by any user without requiring
anything from the sys admin. That's the advantage it has over PPP and
SLIP, which require the cooperation of the sys admin on the network host.
Lots of people have asked about running Mosaic on a Mac or under Windows
over a serial line without PPP or SLIP, but I haven't yet heard about
anyone else wanting to do that under Unix. (Term is a Unix program, and
has so far not been ported to Mac or Windows.) Maybe I'm the only one
in the world with a local Unix machine without SLIP or PPP :-)
-Jim McBeath
jimmc@eskimo.com
Rob Raish wrote (>):
Tony Sanders wrote (>>):
> > > on systems that are not directly connected to the network. Right
> > > now, a SLIP/PPP connection is required to use a graphical browser; these
> > > connections are more expensive to obtain and more difficult to install.
> > >
> > > What can we do to enable communication over a serial line?
> >
> > Doing this right would basically require reinventing SLIP and TCP/IP (you
> > need a reliable connection from end to end, ala tcp).
> Consider this model,
> - Host runs various "proxy" agents which manage TCP sessions with
> services out in the 'great wide.'
> - These proxies are simply 'stubs' which manage the connection and
> feed the data into a communications manager.
> - The communications manager is a simple agent which manages a
> reliable multiplexed channel back to the client. The protocol
> looks something like:
> [Channel Number] 1 octet
> [Packet Type & Data Length mod 2] 1 octet
> [Checksum] 2 octets
> [ ... Data ... ] 2 ... 1024 octets
> - On the client side, there is the other half of the communications
> manager. It breaks each channel out and feeds it to a window.
> - The various windows (I've identified 12 different and useful types)
> take the data and display it. Binary images, Gopher menus, WWW
> browsers, etc.
> - So, each Internet service has a proxy agent which feeds data into
> a communications manager (CM.) The CM multiplexes data over the wire
> to the client, where data if fed to independant windows (or User
> Interaction Agents.)
> One of the issues here is the isolation of complexity. The client side
> handles only those issues which deal with the user, and the server deals
> only with those issues which deal with the communications.
> This is a simple model, extensible, and could be hacked up in a few days.
> I did it once, actually. Would love to see someone take this on as a project.
> (Marc? <grin>)
> </rr>