0

I had a use case where i was planning to poll from browser to server to check any updates for a given customer.Then i thought of exploring push approach where webserver(in my case tomcat) can do it automatically whenever servlet running on webserver gets any update from thirdparty.First question came to my mind how javaclass will know to which browser client it has to send update.Then i came across the link at http://www.gianlucaguarini.com/blog/nodejs-and-a-simple-push-notification-server/. This is the amazing link that demonstrates how push approach can be supported.But i came up with some basic question to go ahead with this approach. These are:-

1)Does browser internally uses the websockets only to communicate with webserver or they just used TCP for that? As per my understanding browser uses only TCP protocol though it is supported by some brosers like chrome,mozilla

2)Does the websocket (provided by io.connect('url')in the example) supported by all browsers specially IE7,IE8 As per my understanding

3)To support the push approach on browser, websockets are the only way to go? As per my understanding, websockets are mainly used to push the data from webserver to browser(only those that support websockets) For this first browser needs to make the websocket connection to webserver.Now server will use the created websocket to emit any data to browser.Right?

4)Is there a possiblity when websocket get automatically disconnected like in case request gets timeout or response is awaited for long time?

5)Do we need to disconnect the socket explicitly or it will be closed automatically when browser is closed?

It would be really helpful if reply is pointwise.

M Sach
  • 33,416
  • 76
  • 221
  • 314

1 Answers1

0

  1. WebSocket protocol is TCP protocol. It's just that it starts as HTTP and then it can be upgraded to TCP.

  2. Internel Explorer is supposed to support WebSockets in version 10. The other major browsers (Chrome, FireFox, Safari, Opera) do fully support it.

  3. There are many other possibilites. Simply polling, long polling ( where you make one ajax request and server responds only when he has new data ), hidden infinite iframe, use of flash, etc.

  4. Yes.

  5. Once an application which is using a port ( in that case a browser ) is killed, then all connections are terminated as well.

leggetter
  • 15,248
  • 1
  • 55
  • 61
freakish
  • 54,167
  • 9
  • 132
  • 169
  • Regarding 3rd point in the answer, thats still a pull approach not a push approach. Right? – M Sach Nov 19 '12 at 09:58
  • Technically there is no much difference. And except for polling it is up to server when to send the data. – freakish Nov 19 '12 at 10:00
  • In the case of polling, we are actually making request from browser on request completion, which is theortically a pulling concept only. As per my understanding true push approach is, browser does not have to make the request to server(once it open the socket).Its the responsiblity of server to push data to browser client – M Sach Nov 19 '12 at 10:07
  • @MSach Client always has to make an initial connection. That's why technically there is no difference. The difference is in support and performance. – freakish Nov 19 '12 at 10:16
  • sorry for extended discussion but want to get the concept clear.I agree that Client always has to make an initial connection. But in case of polling client makes the repeated request to browser which does not happen in case of server push – M Sach Nov 19 '12 at 10:24
  • @MSach Well, yeah, you are right in that with TCP you only make one initial request. That's why HTTP is not suited for real time notifications. However if you want a simple, cross-browser push ( with a delay of course and bigger *is* better in this case :) ), then this is the easiest one. If you want something really proffesional, then I suggest using WebSockets with XMLSocket (Flash) fallback. – freakish Nov 19 '12 at 11:02