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 <[email protected]> wrote: > Hi, > > On Tue, Jun 14, 2011 at 20:03, Guillaume <[email protected]> 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 ? > > Not because of that, but because an intermediary can buffer data > 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. > > Simon > -- > http://bordet.blogspot.com > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz > _______________________________________________ > jetty-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
