On Mon, 27 Dec 2010, amit paliwal wrote:
PLEASE don't top-post. It makes the thread totally confusing to read and
follow.
Well, teh Client will be blocked and it will not be doing a continuous
polling, but the point is not whether it does blocking or polling, the point
is to use server-sent events with HTTP1.1
I don't see how the client's behavior has anything to do with the subject.
libcurl has both a blocking and a non-blocking API so you could pick whichever
solution works best for you.
It is said that HTTP1.1 support server-sent events, which means it should
support asynchronous messages that will be received by client.
"It is said" by whom and where? And where are those "server-sent events"
specified?
libcurl speaks HTTP1.1 pretty well AFAIK, and I'm confident that if your
server remains speaking HTTP1.1, libcurl will talk fine with it!
As I explained: "server-sent events" are typically made with long-polling
clients. (Or using AJAX from within a browser environment.) WebSockets are in
the process of being defined for this purpose...
Well I am interested in libcurl to receive asynchronous messages at any time
as and when server pushes events and also the client should be able to send
GET as and when required.
Possibly your imaginary client would use multiple connections. A client that
receives data from a server can't just reverse and send a GET back, unless of
course the request ended there after the "event" and the connection can be
re-used again for the next request. Thinking about it, it's probably quite
likely that it will work like that as then the client can send whatever it
needs in the request, and then it'll sit waiting for the server again...
--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
