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
