Basically, at least for my problem on hand, it is necessary to modify
both the browser to identify itself and to provide its private listening port,
and the server to "know" each browser's identity and private listening port
(like knowing friends' telephone numbers). In other words, for an
interactive system, the server has to give some states to on-line browsers
while at the same time, not spend more network resources to servicing
browsers than what is required now (the "network-statelessness" ideal).
I've looked a bit at NCSA's recent Common Client Interface (CCI).
On the face of it, it seems that it does not provide sufficient "binding"
between the browser and the server to meet the requirements of my
problem on hand. But I could be wrong.
** Note: This is not to imply anything not good about it.
I just need a different communication model than
CCI's model.
I'm including the attachment below for any discussion or comments.
It does not have complete details but should be sufficient to give an
outline of the approach. Let me know your comments, suggestions,
criticisms, etc either through emailing to me (cheekai@ncb.gov.sg)
or discuss it over this list. Flames will be happily absorbed to cook
my eggs :)
Chin Chee-Kai
cheekai@ncb.gov.sg
http://www.ncb.gov.sg/staff/cheekai/
-------------------------- BEGIN OF INCLUSION ---------------------------
== The Problem ==
While braving the odds and plunging into writing a WWW-based
MUD-style interactive pager, I ran up the same difficulty due
to the "monodirectional" nature of HTTP protocol.
In an interactive system such as a MUD, the server may sporadically
send messages to the client-person who is in a particular room.
== The UID Scheme ==
After thinking through, it seems a solution is possible if the
browser used to connect to the HTTP-MUD server can also attach
a unique ID for all its HTTP requests. This unique ID (UID)
is a combination of machine type (M), OS type (O), login username (L),
timestamp (T) of first initiation of the browser (i.e. this
timestamp doesn't change in subsequent commands sent by this
instance of the browser), process ID (I), and browser's listening
port (P) -- MOLTIP. This "combination" may be a 1-1 function mapping
(M,O,L,T,I,P) --> UID
or an N-to-1 function hash function with a small collision probability
(e.g. < 1%). The implications of a collision means different
instances of browsers (and persons) may appear as the same to
the server side. An example of a 1-1 function for this purpose
can be a concatenation of MOLTIP values casted to lower-case and
separated by hyphens '-':
(M,O,L,T,I,P) --> T-I-P-L-O-M
Eg 19950305130255020-2452-4523-cheekai-sunos4.1.3-sun
The M,O,L fields are clear. The timestamp is in yyyymmddhhmmssiii
format, with yyyy being year, mm being month, dd being date, hh
being hour, mm being minute, ss being second, iii being milisec,
and is in fixed length format so that it may be strcmp()ed to give
a meaningful relational comparison. The I, and P fields should be
straightforward.
The client browser, on initiation, opens a listening port on any
available unused port in the system, but must use the same port
as long as this instance of the browser is alive. It then
computes its UID, and attaches this UID as the first item on each
of its request to the HTTP-MUD server. Eg, "GET /index.html"
now becomes "UID GET /index.html", where UID expands to the
MOLTIP UID value above.
On the server end, all incoming UIDs are cached and tagged with
the browser's host IP address and server's own timestamp.
This server timestamp serves as a Time-To-Live (TTL) check, so that
after a certain time, say 10 minutes, has elapsed and no fresh
request bearing this UID is received, then the server may remove
this UID. To an interactive system like HTTP-MUD, removing a
cached UID implies an action similar to
"Connection closed by foreign host."; in other words, the
interactive system no longer recognises the person/browser bearing
the UID as being "logged into" the interactive system.
To the server, an incoming request from any browser is serviced
as per normal. If the attached UID is present, it is either cached
in the server if it hasn't been, or has its entry refreshed if
the entry already exists. An absence of UID should cause no error.
Whenever the interactive server wishes to initiate an unsolicited
document/message [*] to a browser whose UID is present in the server's
cache, the server will have all the relevant network information
to send its information to the specific instance of the browser.
The server uses a simple protocol (call this HTTP extension, or
Return-HTTP, I don't know :) by first sending a line stating
the browser's UID and other protocol information [*], followed
by "\r\n" (CR+LF), and followed by server's intended HTML documents.
== What's The Big Idea? ==
This UID scheme basically exploits the ports on a client machine
to provide a sort of private "telephone line" to the user.
Current browsers function like telephones with only out-going
communication ability. With the UID scheme, browsers using this
scheme will function like the usual telephones, with two-way
call initiation ability while not deviating too much from existing
HTTP servers; servers which do not wish to implement MOLTIP UIDs
can simply test if the incoming request string begins with numeric
values (assuming the example 1-1 function above is used), and ignore
the first word if a numeric word begins the string.
A browser that does not implement MOLTIP-UID does not listen on
any port for the user and so need not worry about the R-HTTP
protocol which the server uses to return replies to a MOLTIP-UID-
aware browser. A browser which implements MOLTIP-UID listens on
its announced port to the server, and discards any message with
a different UID from its own UID. This is similar to Ethernet's
protocol in which an Ethernet node is exposed to packets to every
node but would only admit packets targetted at that particular node.
== Potential Uses ==
It has almost an immediate use in interactive systems trying to
leverage on well-establishd standards like HTML and HTTP. Interactive
browsing becomes possible when the server can asynchronously initiate
a conversation with a user. This has a direct relevance in, for
instance, an advertisement/classifieds server whereby the availability
of new advertisements/products may be made known to the currently
connected browsers (which will be presumably servicing users interested
in related ads).
MUD - Multi-User Domain - will be possible with MOLTIP UIDs.
New people who just stepped into person A's room can be made known
to A's browser which would otherwise not know who has entered the
room unless A continuously flushes its browser's cache and reloads
the same page over and over again, which is certainly a network-intensive
process.
The use, as I work on this MOLTIP UID spec, seems to extend beyond
just games and interactivity. In a remote and intensive document
search, for example, a HTTP-MOLTIP server can first return an
acknowledgement document saying the search has been initiated.
Since the server already has the browser's MOLTIP UID, it can
close the connection to relieve the browser from being "hung"
while waiting for the server's long searching time. The browser
may, in the mean time, surf through other documents, perhaps
initiating searches on more servers. When the first server
has reached a conclusion to its search (successful or otherwise),
it may package its result (eg, tag copyright/contact information,
compress long documents, etc) and initiate a server->client
reply message to the original browser via its cached MOLTIP UID.
[*] I didn't include the details on "R-HTTP" here to avoid
making this an excessively long mail.
Chin Chee-Kai
cheekai@ncb.gov.sg
http://www.ncb.gov.sg/staff/cheekai/
--------------------------- END OF INCLUSION ----------------------------