On Fri, Dec 31, 2010 at 11:32 AM, Michael Wood <esiotrot_at_gmail.com> wrote:

> Hi Amit
>
> On 31 December 2010 00:34, amit paliwal <amit.ambitions_at_gmail.com> wrote:
> >
> > On Thu, Dec 30, 2010 at 5:25 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> >>
> >> On Thu, 30 Dec 2010, amit paliwal wrote:
> >>
> >>> Which API supports blocking operation with libcurl. I need to get
> blocked
> >>> until Server sends some data, and once it sends data then only do
> >>> curl_easy_perform() to fetch that data.
> >>
> >> curl_easy_perform() is a blocking operation. It will return when the
> >> response has been received. As documented.
> >
> > Reply: Yes, my initial set of operation is happening properly now, but as
> > you might remember we had a discussion on server-sent events, so after
> > initial set, I will be receiving SSE from Server and I need to fetch it
> from
> > socket. If I do second curl_easy_perform() immediately after the first,
> it
> > does not give time to Server to send SSE, so in principal I need to wait
> > until server sends SSE.
> >
> > How will I come to know that server has sent data???
>
> After reading all of your recent messages I have come to the
> conclusion that you have a fundamental misunderstanding of how HTTP
> works and how "server-sent events" must work on top of HTTP.
>

Reply: I know how HTTP works but the problem was the requirement given to
me. If we pass Connection:KeepAlive (following http 1.1) to Server then
server can push events to client, now how to receive these pushed events was
the problem.

>
> To be clear: It is not possible for the server to send something to
> the client unless the client has sent an HTTP request (GET or POST,
> etc.). Also, it is not possible for the client to get something from
> the server unless it is in response to a previous HTTP request (GET,
> POST, etc.)
>
> Also, it seems you may be unclear on exactly what curl_easy_perform()
> does. Whenever you call it, a GET or POST etc. request will be sent
> to the server (assuming the URL you set was http://... or
> https://...). So you cannot use it to "reply" to a "server-sent
> event" from the server, but this is not a problem, because the server
> cannot send you an unsolicited "server-sent event" and will not expect
> a reply to any "server-sent event" it has sent in reply to a prior
> request from the client.
>
> So, basically you are mixing up HTTP and "server-sent events" when it
> would be easier to think of them as being at separate layers.
>
> You should not be doing a "second curl_easy_perform() immediately
> after the first". What you should do is send an initial request and
> wait for the reply. Then the server does NOT reply to your initial
> request immediately. It waits until it has a "server-sent event"
> message that it wants to send you. When it has one, it sends it and
> the client should accept and process it. Once the client has finished
> doing whatever it wants with the "server-sent event" message, it
> should construct a new request to the server containing whatever it
> wants to send "in reply" to the "server-sent event". This should NOT
> be done from your write callback, or if it is it should be with a new
> curl handle. It seems best to me NOT to do it from the callback.
>

Reply: How does the significance of keep alive fits here, I kind of agree to
iot and in past couple of days I absorbed it also. Can server send
idempotent messages to client?

>
> So when the client has a reply it will set whatever options it wants
> on the curl handle and then call curl_easy_perform() again. Once
> again, the server must NOT send a reply immediately, but only when it
> has another "server-sent event" to send to the client.
>

Reply: in this scenario, if we follow http1.1 and the connection is keep
alive can he send more than one server-sent events??

>
> If the client wants to send a different request that it needs an
> immediate response to (i.e. not a "reply" to a "server-sent event")
> then it can do that e.g. on a new curl handle and the server must know
> that that request needs an immediate response.
>
> I hope that clarifies things for you.
>
> --
> Michael Wood <esiotrot_at_gmail.com>
> -------------------------------------------------------------------
> 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-31