On Fri, Dec 31, 2010 at 11:32 AM, Michael Wood <[email protected]> wrote:
> Hi Amit > > On 31 December 2010 00:34, amit paliwal <[email protected]> wrote: > > > > On Thu, Dec 30, 2010 at 5:25 PM, Daniel Stenberg <[email protected]> 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 <[email protected]> > ------------------------------------------------------------------- > 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
