On 31 December 2010 19:26, amit paliwal <amit.ambitions_at_gmail.com> wrote:
>
> On Fri, Dec 31, 2010 at 11:32 AM, Michael Wood <esiotrot_at_gmail.com> wrote:
[...]
>> 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.

No, because the client would not expect them. If the server sent
something to the client without the client having requested anything,
then this would not be HTTP.

Connection: KeepAlive is to allow the client to send multiple requests
to the server over the same TCP connection, so as far as I can see it
has nothing to do with "server-sent events". "server-sent events"
could go over a connection that was kept alive or else could go over
separate connections. I don't see how it makes a difference, given
how HTTP works.

>> 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.)
[...]
>> 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

As mentioned above, I don't think keep alive has anything to do with
this. It would be at a lower layer and not something that
"server-sent events" would need to care about.

> iot and in past couple of days I absorbed it also. Can server send
> idempotent messages to client?

By "idempotent messages", do you mean something like this?
http://bill-poole.blogspot.com/2008/06/idempotent-messages.html

It seems to me that that is something that would only matter at a
higher layer and libcurl would not need to worry about it. Your
server and client code would need to be able to handle duplicated
messages properly.

>> 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??

Only if the client sends more than one request. The server can only
send a "server-sent event" message in response to an HTTP request from
the client.

-- 
Michael Wood <esiotrot_at_gmail.com>
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html