[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
required?
the trim() bug was fixed last week, please update cvs.
This was tested on Win32 and OSX.
Regards
Martin
--
http://www.xmlBlaster.org