0

I was trying to understand the difference in Websocket and Comet model. As per my understanding,

In comet model, the connection remains opened until the server has something to push to the client. Once server pushes the data to client, the connection is closed and new connection is established for the next request. It is not considered a good approach as the connection may remain open for long time (causing intensive use of server resources) or may timeout.

On the other hand, websockets start with a handshake connection and once both the client and server agree to exchange data, the connection remains open.

So in both the case the connection remains open for long time (especially websocket). So isnt't this a drawback of websocket to keep the connection open. I would like to take the reference of SignalR in asp.net to discuss about this concept.

Tech Jay
  • 404
  • 1
  • 6
  • 16

1 Answers1

1

First, let's clarify that Comet comes in two flavors: HTTP Streaming and HTTP Long Polling. You were referring to Long Polling. (See this other answer for terminology).

In all three cases (WebSocket, HTTP Streaming, and HTTP Long Polling) the underlying TCP socket is kept open. That's actually the main feature of this kind of techniques and not a side effect. You want the socket to stay permanently open (I'm oversimplifying now), so that data can be pushed asynchronously and with low latency.

As you correctly said, this implies that the server must be able to handle a large number of open sockets without wasting resources. And that's one of the key elements in the choice of a good Comet/WebSocket server.

Community
  • 1
  • 1
Alessandro Alinone
  • 4,934
  • 2
  • 18
  • 22
  • What i understood from this link: http://stackoverflow.com/questions/9107384/server-scalability-html-5-websockets-vs-comet, is that when u have messages in queue to be sent to the client, from server, in that case, comet will polling will have to wait until u send a request for it (as it is not full-duplex - correct me if i am wrong). But being full duplex, websocket will keep sending the queued messages, even when it is fulfilling ur current request. Please correct me if I am wrong here. – Tech Jay Jun 03 '15 at 15:39
  • In long polling, If the underlying TCP connection remains open, it does get's closed when the next request is sent for long polling ??? – Tech Jay Jun 03 '15 at 15:48
  • Full-duplex doesn't mean pipelining. Full-duplex means being able to send messages bidirectionally (from the server to the client and from the client to the server) at the same time on the same socket. Pipelining means being able to stream messages without waiting for some sort of application-level ack or new request from the client to get the next message. WebSocket is full-duplex with pipelining. HTTP Streaming is not full-duplex but has pipelining. HTTP Long Polling is not full-duplex and doesn't have pipelining. In Long Polling, the underlying TCP socket usually stays open across requests. – Alessandro Alinone Jun 04 '15 at 08:36
  • So what I can finally conclude that the underlying tcp connection that remains open. In case of long polling its the request that ends after receiving the response and new request is sent again. So its upto the user to decide which technique to use as pointed out by @Alessandro – Tech Jay Jul 01 '15 at 04:26