Matthew Veenstra wrote:
> libcurl is not a server and cannot listen for HTTP traffic. HTTP
> clients are not servers at the same time, they must always request
> data. I am pretty sure this is part of the HTTP spec.
>
> If you want data fed on demand you should look at some messaging
> service. Jabber or such might suit you needs.

He might need to interface with an existing service, so he'd have to
use whatever protocol it uses.

And it might be a HTTP client he wants, with the data requested by the
client.

There is a mode where the data is not delivered immediately by the
server. The connection stays open, with the client waiting until the
server is ready to send a message. This is called various names such
as "HTTP push", "HTTP streaming", "delayed HTTP", "reverse AJAX",
"Comet" and "publish-subscibe" to pick just a few.

The HTTP spec doesn't recommend or disallow this. Intentional time
delays are outside it's scope.

This is a dirty trick to get messages initiated on the server side
over HTTP, but with some client cooperation.

Despite being a dirty trick, it is done because this is the only way
to do server-initiated messages from a web browser. Things like data
changing in a web page when something on the server changes.
Otherwise, there's no way to do it (unless using Flash or Java
plugins). Naturally, there are reliability problems with various
browsers... but sometimes it's worth doing despite the problems.

It's possible to poll the server every few seconds for a similar
effect, but that is less rapid response (think of instant messaging or
real-time status displays), and it uses more resources everywhere,
including on the server (despite popular misconception, probably due
to using the wrong kind of server software for this sort of thing).

Because these servers exist and do useful things, naturally, someone
now wants to write a client which can access these servers and isn't a
web browser :-)

Hence, perhaps, the first question:

> On Oct 22, 2007, at 2:12 PM, Wiseman, Andrew (Mission Systems) wrote:
>
> What I wish to implement using your API is the ability to receive
> asynchronously data being published from a remote host running a
> program built and maintained by another company. It is the usual
> pub/sub paradigm where I (client) first send a subscribe message to
> them (via HTTP) and thereafter, as data becomes available, receive it
> on my side.

Actually, there are many different variations on the pub/sub pattern,
especially over HTTP.

> Is the libcurl API designed to support this and, if so, are there any
> sample/example programs that I could use as a starting point (as in
> your example folder)? Or is it that libcurl does not support
> publish-subscribe and I need to go elsewhere.

That depends what flavour of pub/sub you are using. Are you designing
your own, or interfacing with an existing service?

If you're designing your own pub/sub protocol, the suggestion to use
an existing message protocol like Jabber or BEEP, or anything other
than HTTP(*) in fact :-), is probably a better one.

(*) except for all those XML-RPC and SOAP flavours of pub/sub
messaging, where both ends have to be a client and server at the same
time.

The short answer is your question isn't precise enough. There's
several different kinds of pub/sub over HTTP, and they are implemented
in different ways at the client and server. You didn't say if the
data becoming available is sent in HTTP delayed responses, or in HTTP
callback-style requests to your client.

> Also is there a way to tell libcurl to listen on a specific port for
> incoming HTTP traffic?

No, libcurl is a client, not a server :-) That's asking for a HTTP server.

-- Jamie
Received on 2007-10-23