[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-users] Continuation and streaming
|
Thanks for your answer.
I wasn't aware of that an intermediary can buffer data, in fact I don't know a lot about networks.
In fact, the application I work already on use an implementation of comet long polling. The connection can remains active for hours and this surprise because I thought that networks equipment could close an HTTP connection that lives too long. Someone told me that because it was HTTPS, no equipment try to cut the connection because it can knows what was doing the connection.
Do you think this explanation is correct (I try to have different sounding) ? Can it prevent intermediary to buffer the response too ?
On Tue, Jun 14, 2011 at 8:51 PM, Simone Bordet
<sbordet@xxxxxxxxxxx> wrote:
Hi,
On Tue, Jun 14, 2011 at 20:03, Guillaume <
itchy75@xxxxxxxxxx> wrote:
> Do you mean that an network equipment between the server and the client
> can interfere with the connection because it will be open a long time ?
because it understands HTTP.
For example, chunking with different sizes.
> Should I use a pattern like open -> send -> close ?
That would work, but depending on the traffic will be troublesome for
the TCP stack.
> I will check websocket, but from what I understand it will open an
> connection that I can use as a duplex connection (we can't do that with
> HTTP). Why this kind of connection will less suffer from network equipment ?
Hopefully it will be better defined for intermediaries.
But of course it needs to be widely adopted.
> I will also have a look at cometD, but for the moment the client just have
> to open a connection and the server send messages without the user needs to
> request to listen to a topic.
There is no much difference between listening to a single topic or
opening a connection with your own procotol.
Your call though, but of course CometD has already solved issues like
scalability, concurrency, firewall traversal, simple API, connection
management (is your client dead ? is your server dead ?), automatic
retries, timeouts, clustering, etc. etc.
