[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster-devel] c sockets

Martin Johnson wrote:
Hi All,

Hi Martin,

I tried to post earlier today and was rejected and asked to repost, it was hours and hours ago.

I will try again but forgive me if this turns into a repeat message.

XmlBlaster server has been working pretty much out of the box on both dual
G5 and G4 with OSX 10.3.x.
Which is has really cheered me up ;-)

Though the challenge has come from the fact that these OSX machines are
allowed an outbound connection only, NO Listening.

The C socket protocol performs this function. Perfect.

But now i want to have update() called as well (on the same socket) instead
of get().  Can i do this?

Yes, this is the default behaviour, we tunnel the callback back in the same socket. Just try it.

Can i have configure xmlBlaster server somehow to place update() calls to client on the same outbound only connection made by the client?? The documentation sort of alludes to it though I can only see get() being used.

I know you have on the TODO list a thread pool. For this are you thinking of
a select() loop calling out to
callbacks to handle reads etc something like a Reactor pattern..
Currently a separate thread blocks on the socket and
delivers callbacks back to the client.

Doing it single threaded with select() would be another solution
probably we can patch the tiny C code to support both variants.

Also I believe there is a small bug with trim() and scanning msgLen sizes. It works upto 9999 bytes and then fails.

eg: "      9999" arrives, trim() turns it into "9999  9999", fortunatly
sscanf() breaks on the space.
eg: "     10000" arrives, trim() turns it into "1000010000", unfortunatly
sscanf() does the right thing again.

The max allowed 1000000000, guess what happens.

sscanf() can actually parse the original "      9999" so is trim() really

the trim() bug was fixed last week, please update cvs.

This was tested on Win32 and OSX.