Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Continuation and streaming

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 ?

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


Back to the top