Re: Example: VMS to Web Browser "push" technology

Hi Jan-Erik,

Yes, I was thinking about that part. How the client
would "subscribe" to the information.

The method I described is pretty standard, where the service-provider keeps
a track of registered clients and distributes any incoming data to the list
in a round-robin fashion. (Subscriptions usually have to be renewed every N
mins)

One alternative could be that, for every Tier3 client that logs-on, you keep
a list of VMS Usernames and IP addresses(+/- ports) in a system-wide
database that can be accessed by utilities such as $REPLY/USER or "You've
got new mail" or "Your print job is finished" or "Fred wants to chat" or
whatever. . .

A totally different method of "subscribing" is (with, I believe, the
restriction of only being available via subnets) to UDP "broadcast" messages
to all clients that subscribe to a particular IP address. In this case the
server, or service provider, has no knowledge of who the clients are (and
quite frankly doesn't give a toss :-) Furthermore, and as alluded to in my
previous post, "Multicasting" is the mutt's nut's for wide-area message
dissemination, but there appear to be some real obstacles with public
networks.

I'm seeing a "factory dashboard" application
showing "daily production" typ of info. Makes
upper management happy... :-)

Look, polling is anathema to me but let's give the devil his due; if *every*
movement in *every* instrument is to become a broadcastable event then
you're not gonna be doing much else but servicing redundant, stale event
data. I'm guessing that polling, at a user-configured interval, for a whole
bag-full of statistics might suit your dashboard better - a la mode de
RMU/SHOW STATS. Alarm-processing OTOH lends itself beautifully to the
unsolicited and asynchronous capabilities of my example! Stall-Messages?
Disk Statii? Cluster State transitions? All good stuff!

B.t.w, I'm not updated on the actual UDP vs. TCP
differences. Was there some special reason to use UDP ?
Whould it be harder (more complex) to use TCP instead ?

At least you're honest! (And you're hardly going to be enlightened at a
Bootcamp soiree for the under-utilized and overpaid. But then you did get
your beloved gSOAP so I guess you're happy, even though the rest of us are
dying for want of a XHR$ RTL :-( Argh. . .the bitterness consumes me!)

Here's a few differentiators that might interest you (Hopefully others will
chime in, and I'm sure there are oodles of white-papers from the IMM team et
al, on what you should be doing with your IP network)

1) TCP/IP is a connection-oriented, reliable protocol for delivering streams
of data
2) UDP is an unreliable connectionless protocol for delivering data packets
in no guranteed sequence or without duplication/loss
3) SSL can be layered on TCP/IP but not UDP (Lovely IPsec covers it all!)
4) Because UDP is connectionless, any number of servers can supply data
simultaneously
5) With UDP you often need to use sequence number checks, heartbeats, and
timeouts to maintain pseudo-connections
6) TCP/IP is reliable, robust, let's you know when the peer dies and also
has OOB data

In a nutshell, a context-rich, connection-oriented protocol like TCP/IP (or
DECnet for that matter) under the control of Tier3 Client/Server Middleware
is the best fit for clients who want to simply "logon" and maintain a
context-rich session with their chosen application(s). UDP is best suited to
delivering asynchronous, and pehaps unsolicited, data into the equation.
Alles klar?

If OTOH you'd like to listen to every pointless knobhead in the industry,
then you may well come to the conclusion that: -
1) There is no benefit in maintaining a persitent connection between client
and server because who's to say that you'll want to visit that same server
again anyway? Somewhere between show balance/make withdrawl?
2) Session Ids, Cookies, and waving a dead-chicken over your head, are more
than adequate mechanisms for maintaining the barest minimum of state
information 'cos anything else wouldn't be truly RESTful.
3) Session hijacking isn't important.
4) OTOH a persistent connection *is ideal* for asynchronous message
broadcasts - Disbelief!
5) Much better than polling, long-polling, streaming, cometting, chunking,
and plain-bullshitting!
6) HTTP "standard" says maximum of 2 connections per server but "vie have
vays" of defeating such controls (Just like the cross-domain Ajax check!)
7) Just because, at the end of the day, we have a dedicated connection and a
dedicated server process per each client doesn't mean that we should have
just stuck with INETd
8) HTTP is just the most bestest, highest performing, and secure midlleware
backbone for all your application needs
9) Anyway, we own port 80 and anything else means you have to modify your
Firewalls. Nah nah nanah-nah!

Anyway, the Olympics beckon. . .

Cheers Richard Maher

PS. mysql, interpretters, Perl, Python, PHP, Linux - It's all good; Just
what has VMS got to do with all this?

"Jan-Erik Söderholm" <jan-erik.soderholm@xxxxxxxxx> wrote in message
news:z5Rmk.1563$U5.857@xxxxxxxxxxxxxxxxxx
Richard Maher wrote:

...and tell a detached VMS process to include your client's IP
Address/port in its list of customers

Yes, I was thinking about that part. How the client
would "subscribe" to the information.

I'm seeing a "factory dashboard" application
showing "daily production" typ of info. Makes
upper management happy... :-)

B.t.w, I'm not updated on the actual UDP vs. TCP
differences. Was there some special reason to use UDP ?
Whould it be harder (more complex) to use TCP instead ?

Jan-Erik.



.