On Tue, Dec 28, 2010 at 3:42 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Mon, 27 Dec 2010, amit paliwal wrote:
>
> Reply: please refer to http://dev.w3.org/html5/eventsource/ standard.
>>
>
> That is an API defined by the W3C. That API works on top of HTTP yes, but
> it can't change the way HTTP works.
>
> HTTP is defined in RFC2616 - which is being updated by the IETF httpbis
> working group (in which I participate). libcurl speaks HTTP pretty good.

Reply: thanks Daniel, i agree to what you are saying, but my point is
simple, and in fact it is my question that if SSE is supported it means
server can push events any time, right? And if it pushes events then the
Client should be able to receive those events and reply to those events,
which is not typical request response. My scenario is simple and goes like
this:

1) Client will initially send HTTP GET and get the response from the server
and then it will be having persistent connection with Server.
2) Server can push events at any time, and the Client shoul;d be able to
receive those events on top of HTTP as payload.
3) client should be able to reply.

Second scenario:
----------------------------
1) client will send HTTP GET messages
2) Server will reply with HTTP OK response.

Second scenario is easy to get. I need your inputs for achieving first
scenario.

>
>
> It says server-sent events can be passed on top of standard HTTP, server
>> sent events abbreviated as SSE is a technology to push events to client any
>> time, so it means any client having persistent HTTP connection should be
>> able to receive SSE (which is asynchronous data) from server. Now normally
>> HTTP is a request-response model, where the client send the request and wait
>> for the response. for SSE we need not to first sent a request, and this is
>> why I asked whether we can do it by libcurl or not.
>>
>
> I'm sorry, but that's not how I would describe things. HTTP is always
> request- response and adding an API on top of it doesn't change the way HTTP
> works. As the page you linked to also describes, SSE is still
> request-response and it does exactly what I previously guessed: the client
> makes a request and the connection is kept alive for a long time during
> which the server feeds the client with data according to the spec.

Reply: I agree to this, my qords might have confused you but I mean the
same, Client will keep the connection open and my only concern is in knowing
that will Client be able to receive SSE on that socket connection and send
response by using libcurl.

>
>
> If some SSE comes on socket, will libcutl call my callback's for header
>> and payload? and if yes, then after parsing will i be able to send a GET
>> message by calling curl_easy_perform()?
>>
>
> libcurl offers both blocking and non-blocking interfaces and you can decide
> which one is best suited for your application. When the write callback has
> got enough data to construct a single SSE message you can fire it off.

Reply: Client will not send SSE, SSE will be received by Client and we need
to parse it.

Thanks a lot for you responses, kindly bear a bit more with me and let me
achieve this scenario.

>
>
> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html
>

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-12-28