struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raghu Kanchustambham <>
Subject Re: Web Push Technology
Date Thu, 05 Jan 2006 04:13:31 GMT
Agreed Frank that Applets pose these "security" restrictions. I forgot to
mention that part of the story .. may be got lost in my previous long rant!

Let me take a different route now and see what you think about it.

The problems that we have been discussing all this while is because HTTP is
inherently pull based and stateless (in its most natural form my connections
are not 'persistent' over multiple requests).

One thing I am just wondering right now is, whether I need to really run
this "alerting push" communication over HTTP ? Why not I have the applet
open a connection to another "plain-socket-listening-server" (not the same
HTTP server) which keeps the connection 'alive' for this client? The rest of
application continues to be 'powered' by the HTTP server, but just the
alerting part can take a different route, where the applet could make a new
connection to a new server/port and hence cutting out HTTP alltogether!

Now I agree, the same security and permissioning concerns remain but just
wondering if this is a better model though. The firewall needs to open up
for non-HTTP traffic etc.. but just curious if this makes sense.

What do you think?


On 1/5/06, Frank W. Zammetti <> wrote:
> On Wed, January 4, 2006 1:03 pm, Raghu Kanchustambham said:
> > I would disagree on your conclusion that pull is *the* way to achieve
> your
> > 'push alert' on http.
> No, I didn't say *the* way, I said it probably was the best option, all
> things considered :)
> > Some points on which you will base your decision maybe as follows:
> > 1. How frequent do I expect to get alerts? Some thought on the
> probability
> > distribution of these alerts may be useful while architecting the right
> > mechanism. For example, if I know that every 10 seconds I would
> > 'more_or_less' expect one update that needs to be 'pushed', then I would
> > go
> > with the AJAX model and let the client "pull" every 10 seconds.
> No argument :)
> > However, if there is no certainity of the frequency of change events
> that
> > need to be pushed and if long 'silence' periods are expected (which may
> or
> > may not be interspersed with bursty updates) then I would go the applet
> > way
> > and let the server "push" when the event needs to be notified. This
> saves
> > me
> > the "poll traffic" on the network. Imagine polling every 10 seconds,
> when
> > the change occured only after an hour!
> While I'm not saying you couldn't do an applet, and that your reasoning
> isn't perfectly reasonable, think about all the problems an applet
> presents... does the browser have a JVM installed and enabled? (reasonably
> safe to assume yes, certainly no bigger a problem than asking if
> Javascript is available).  Is the client behind a proxy?  If so, how can
> you be sure you are getting their *real* IP address?  And even if you got
> it, (a) chances are its a private network address and (b) the proxy
> probably isn't going to allow incoming requests (this is perfectly normal
> with NAT).  At *best* your going to have problems with a large part of
> your audience if this is a public site.
> Of course, if we're talking back-office here, many of these problems go
> away.  But then again, if you have or do now work in a big organization,
> you know that even simple firewall changes when you have multiple
> locations across a WAN can be a headache :)
> > So choose wisely between the AJAX 'pull' model vs. the Applet (or
> > someother
> > client control) 'push' model :-) You will need to analyze the domain a
> bit
> > and understand the distribution over time for the events to be able to
> > come
> > up with a good architecture! :-)
> I think the key point here is to look at the expected alert distribution
> and make your decision based on that.  We can talk generalities here, but
> the developer has to deal with the specifics and make the appropriate
> decisions.
> > The other important question you need to ask is "are all the changes
> > important or can I miss out to send some changes to the client?"  If the
> > answer is that you can miss out, then AJAX is ok. Imagine you poll every
> > 10
> > seconds, but 3 events happen in those 10 seconds, you would be able to
> > push
> > out only the latest change (unless the server maintains the list of all
> > changes). In case of push, you may not loose any event.
> True, but I would think *any* solution, be it push or pull, has to deal
> with this.  I mean, if your pushing out 3 events in 10 seconds, there is
> no guarantee that network traffic won't make that first push take 20
> seconds, in which case you would miss the last two events, so you would
> have to enqueue them in any case.  Arguably, if this is a frequent enough
> occurance, then pull might be better because if you poll every 10 seconds
> and find 3 events, it is a single request to get them all if they are
> queued up, but a push would fire off 3 requests (or would wait some
> defined period of time for the queue to build up and then push them *all*
> out at once).
> > Hope this helps you in your decision.:-)
> As do I :)  There's nothing more fun than a couple of architects arguing!
> :)
> > ~Raghu~
> Frank
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message