under linux:
glibc-2.2.5 (debian-unstable)
SDL_net-1.2.4 (and 1.2.0 fwiw)
SDL_websrv-0.1.1
SDLNet_TCP_Recv doesn’t detect a broken (or closed) network connection.
and SDL_websrv goes into a loop at WebSrv_ClientReadLine if this happens
as it always returns 0.
current workaround - if SDLNet_TCP_Recv reads 0 characters I close the
connection…
Now I realize both packages aren’t considered terribly important by folks
here wry grin but I’m rather enjoying playing with them.
I’ve managed (by umm rewriting other large sections not associated with
SDL_net management 
to get my own modified web server going with support
for XMLRPC. Why? At this point I’m thinking hack value…
The only problem I’ve got is while the first transaction (I added HTTP/1.1
support including open connections) completing successfully, all
additional http/XML transactions timeout - because of that loop I
described above. (note of course that as SDL_WebSrv normally closes a
connection once data’s delivered this isn’t normally a problem)
The entire server is running inside a single SDL_thread because it seemed
to make more sense that way
oh I use xmlrpc-c-0.9.9 for XMLRPC handling. I looked at the abyss
webserver delivered with it but it’s use of fork() and requirements for
running as non-root g meant I stopped using it. Besides, SDL_WebSrv is
a better design in a lot of ways
and I’m using paragui (CVS version g) for the front end in the program
I’m writing but it’s only used in the XMLRPC stuff for it’s ‘slot’ support…
G’day, eh?
- Teunis
Teunis Peters wrote:
under linux:
glibc-2.2.5 (debian-unstable)
SDL_net-1.2.4 (and 1.2.0 fwiw)
SDL_websrv-0.1.1
SDLNet_TCP_Recv doesn’t detect a broken (or closed) network connection.
and SDL_websrv goes into a loop at WebSrv_ClientReadLine if this happens
as it always returns 0.
I see, I’ll fix this in the next update of SDL_websrv.
current workaround - if SDLNet_TCP_Recv reads 0 characters I close the
connection…
yes, this will be done in SDL_websrv now.
Now I realize both packages aren’t considered terribly important by folks
here wry grin but I’m rather enjoying playing with them.
I’ve managed (by umm rewriting other large sections not associated with
SDL_net management to get my own modified web server going with support
for XMLRPC. Why? At this point I’m thinking hack value…
while adding stuff to SDL_websrv is great, SDL_websrv was designed to be as small as possible.
So as to not increase run size by much if someone wants to add a webserver…
The only problem I’ve got is while the first transaction (I added HTTP/1.1
support including open connections) completing successfully, all
additional http/XML transactions timeout - because of that loop I
described above. (note of course that as SDL_WebSrv normally closes a
connection once data’s delivered this isn’t normally a problem)
SDL_websrv is just HTTP/1.0 stuff at the moment…
I was looking into adding more, but am still working on fixing the multipart post parsing,
since web browsers seem to like to do weird things to their multipart separators groan
I do want to add more functionality as seems appropriate…but for now, a single connection
read - write - close, seems to do most things that I could think of
however I know people want to do weird things…so I’m open to additions…
please make any patches, and also try to make large additions optionally compilable in the
configure.in setup, so that people can still get the tiniest functional web server still
The entire server is running inside a single SDL_thread because it seemed
to make more sense that way
oh I use xmlrpc-c-0.9.9 for XMLRPC handling. I looked at the abyss
webserver delivered with it but it’s use of fork() and requirements for
running as non-root g meant I stopped using it. Besides, SDL_WebSrv is
a better design in a lot of ways
wow, someone actually using my SDL_websrv stuff and likes it heheh…–
-==-
Jon Atkins
http://jcatki.2y.net/
Teunis Peters wrote:
under linux:
glibc-2.2.5 (debian-unstable)
SDL_net-1.2.4 (and 1.2.0 fwiw)
SDL_websrv-0.1.1
SDLNet_TCP_Recv doesn’t detect a broken (or closed) network connection.
and SDL_websrv goes into a loop at WebSrv_ClientReadLine if this happens
as it always returns 0.
I see, I’ll fix this in the next update of SDL_websrv.
This happens to be a bug in SDL_net actually - or more likely glibc…
sigh. Or some interaction between the two. SDL_websrv -shows- the
problem that’s all. But only if one runs multiple clients… and I think
one has to leave the connection open too on the server end
specifically the ‘recv’ function returns a size of ‘0’ with no error if
there’s no data available and the client’s closed the connection. As
’recv’ is used in the linux implementation of SDLNet_TCP_Recv, that sort
of narrows it down.
current workaround - if SDLNet_TCP_Recv reads 0 characters I close the
connection…
Note that this workaround works for me
oh the long and the short of my changes - as of this point now that I’ve
narrowed down and got a workaround for this issue (I have yet to try it
under windows yet - next the whole http/1.1 server seems to work so
far… but I’m still playing with ideas
(I’ve got base64 file transmission that seems to work so far as well
hrm. Whether this go patch or branch I dunno…
I haven’t needed to look at post/multipart yet though.
But I do like the design I’ve just played with the copy on my system a
lot.
G’day, eh?
- TeunisOn Mon, 27 May 2002, Jonathan Atkins wrote: