[WIN32] apr_sockets BUG?

[Mladen Turk <mt...@mappingsoft.com>]

Hi,

Dunno if I miss something, but the server/client test on WIN32 doesn't work.
Well, as far I've been able to track the things down the non-blocking
sockets are the bugger.

Server dump:

server: Initializing............................ OK
server: Creating context........................ OK
server: Preparing getopt........................ OK
server: Creating new socket..................... OK
server: Setting option APR_SO_NONBLOCK.......... OK
server: Setting option APR_SO_REUSEADDR......... OK
server: Binding socket to port.................. OK
server: Listening to socket..................... OK
server: Setting up for polling.................. OK
server: Polling for socket...................... OK
server: Accepting a connection.................. OK
Server socket: 127.0.0.1:8021 -> 127.0.0.1:3044
server: Receiving data from socket.............. Failed
Error (32535): apr_recv(sock2, datasend, &length)
A non-blocking socket operation could not be completed immediately.

Client dump:

Initializing.........OK
Creating context.......OK
        Client:  Making socket address...............OK
        Client:  Creating new socket.......OK
        Client:  Setting socket timeout.......OK
        Client:  Connecting to socket.......OK
        Client socket: 127.0.0.1:3044 -> 127.0.0.1:8021
        Client:  Trying to send data over socket.......OK
        Client:  Trying to receive data over socket.......Problem receiving
data
: An established connection was aborted by the software in your host
machine.
(32553)


Now, If I change the server code from:
    APR_TEST_SUCCESS(rv, "Setting option APR_SO_NONBLOCK",
        apr_setsocketopt(sock, APR_SO_NONBLOCK, 1))
to:
    APR_TEST_SUCCESS(rv, "Setting option APR_SO_NONBLOCK",
        apr_setsocketopt(sock, APR_TCP_NODELAY, 1))

everyting work fine :)

MT.

RE: [WIN32] apr_sockets BUG?

[Mladen Turk <mt...@mappingsoft.com>]

> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Friday, April 19, 2002 7:23 PM
> To: Jeff Trawick
> Cc: Mladen Turk; APR Dev
> Subject: Re: [WIN32] apr_sockets BUG?
>
> > > Dunno if I miss something, but the server/client test on
> WIN32 doesn't
> > work.
> > > Well, as far I've been able to track the things down the non-blocking
> > > sockets are the bugger.
> >
> >It seems to me that server.c is a bit naive in thinking that data will
> >be available as soon as it accepts a new connection.  You could add a
> >poll for data available before the apr_recv() in the server.
>
> Or... is this running on WinXP (or possibly, Win2K?)  There is a
> rather big
> nonblocking socket driver bug, see /dist/httpd/binaries/win32/
> and follow the
> "XP Users Read Me First" dialog, where I've cited the Q article
> that Allan's
> research led to.
>
> Bill
 I love the service packs :(

Q317949 addresses the cross-process issues, but the apr-test server.c is not
a such app.
The results are the same on WinXP Pro and Win2K Server (with sp2).

MT.

Re: [WIN32] apr_sockets BUG?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 06:16 AM 4/19/2002, Jeff Trawick wrote:
>"Mladen Turk" <mt...@mappingsoft.com> writes:
>
> > Hi,
> >
> > Dunno if I miss something, but the server/client test on WIN32 doesn't 
> work.
> > Well, as far I've been able to track the things down the non-blocking
> > sockets are the bugger.
>
>It seems to me that server.c is a bit naive in thinking that data will
>be available as soon as it accepts a new connection.  You could add a
>poll for data available before the apr_recv() in the server.

Or... is this running on WinXP (or possibly, Win2K?)  There is a rather big
nonblocking socket driver bug, see /dist/httpd/binaries/win32/ and follow the
"XP Users Read Me First" dialog, where I've cited the Q article that Allan's
research led to.

Bill

Re: [WIN32] apr_sockets BUG?

[Jeff Trawick <tr...@attglobal.net>]

"Mladen Turk" <mt...@mappingsoft.com> writes:

> Hi,
> 
> Dunno if I miss something, but the server/client test on WIN32 doesn't work.
> Well, as far I've been able to track the things down the non-blocking
> sockets are the bugger.

It seems to me that server.c is a bit naive in thinking that data will
be available as soon as it accepts a new connection.  You could add a
poll for data available before the apr_recv() in the server.

More easily you could set a timeout on the socket, but then we already
test that with client.c I believe.

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...