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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
