Re: recv blocks although socket is ready

Ok it seems to work now. However the code is more bulky this way. Most
of the members of the interface in my network layer have blocking
semantics. Only one has non-blocking semantics. Before I could just
call any socket operation and rely on the socket to block. In only one
case I had to check (using select) wheter the socket would block and
then abort. Now I have to implement blocking myself in all other
members by calling select in a loop as long as the socket oparation
returns EWOULDBLOCK.

I still think it should have worked the other way and that there might
be a bug somewhere in the socket implementation...

Anyway, thanks for helping!

Michael

Alexander Nickolov wrote:
Arkady's point is that using select you can present blocking
semantics using a non-blocking socket. I believe you
already do that - select is typically not used with blocking
sockets after all...

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@xxxxxxxx
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================

<314.michael@xxxxxxxxx> wrote in message
news:1163419851.259728.39340@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Yes sure. That is not a problem. The problem is, that in blocking mode
select sometimes reports the socket readable and then the following
recv() blocks. Anyway, yesterday I changed the implementation to use
non-blocking sockets. But I wont be able to test it until friday when I
have access to the lab where the problem actually occurrs.

Michael

On Nov 13, 9:05 am, "Arkady Frenkel" <arka...@xxxxxxxxxxxxxxxx> wrote:
Any case you can sit forever ( up to data come ) on select() in
non-blocking mode as you are blocked
Arkady

<314.mich...@xxxxxxxxx> wrote in
messagenews:1163348057.752364.325540@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

I will try the sniffer thing if I get to it. Thanks for the hint.
I'm not sure if changing to non-blocking mode is really an option. The
application abstracts different network layers (tcp, udp with some
custom flow control, infiniband, quadrics teac...) into a common
interface. So I'd have to find a way to implement this without changing
the semantics of the interface. That is, I have to simulate blocking in
code for those members of the interface which have blocking semantics.

Michael

On Nov 12, 7:57 am, "Arkady Frenkel" <arka...@xxxxxxxxxxxxxxxx> wrote:
But non-blocking mode is what implemented in winsock from BSD, that
should
work on any platform, so worth to try that for sure, OTOH check if
really
data arrived with some kind of sniffer at that moment.
Arkady

<314.mich...@xxxxxxxxx> wrote in
messagenews:1163261680.469048.85120@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Because this is a cross plattform application for AIX, Darwin,
FreeBSD,
IRIX, IRIX64, Linux, OSF1, SunOS and Windows. I doesnt' make sense
to
change something which works on all other plattforms and which ought
to
work on Windows too. I'd rather like to know if this is a known
issue
with blocking sockets, select and receive. If so I'd implement a
temporary fix until the issue is being addressed. If not, well I
guess
I'm on my own ;-)

Michael

Alexander Nickolov wrote:
Why don't you make your socket non-blocking? Then
you'd get WSAEWOULDBLOCK which you can ignore.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnicko...@xxxxxxxx
MVP VC FAQ:http://www.mvps.org/vcfaq
=====================================

<314.mich...@xxxxxxxxx> wrote in message
news:1163184119.063002.123900@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I have a strange problem using select() and recv(). Intermittedly
it
occurs, that even though select() reports the socket to be
readable
the
following call to recv() blocks. When I shutdown the other peer
of
the
connection recv() returns and WSAGetLastError() returns
WSAESHUTDOWN.
This only occures on our Dell Workstation PWS670. I couldn't
reproduce
it on a different machine. I replaced the NIC with a different
modell
from a different vendor and installed a different driver but the
problem persited. Running the same app on the same hardware under
Linux
I was not able to reproduce the problem though.

Another point which seems worth noting is, that the problem
occurs
more
frequently when there is some UDP traffic on another socket. This
traffic is consumed by another thread in my app which isn't
affected
by
the blocking of the main thread.

My setup:
- Dell Workstation PWS670 4xXeon 3.6GHz, 3GB RAM,
- Intel(R) PRO/1000 MTW NIC or ProG-2000S (with Realtek driver)
- Windows XP SP2 (almost) fully patched

Any ideas?

Thanks,
Michael


.

Relevant Pages

  • Re: send(2) does not block, send(2) man page wrong?
    ... To implement a blocking sendon UDP sockets, ... into some kind of list hanging off the interface, ... the socket, the delay would become unbounded as well. ...
    (freebsd-hackers)
  • Re: Sockets causing deadlock
    ... My mistake if I said non-blocking. ... They are actually blocking. ... Allocate a new socket ... Status = connecting ...
    (microsoft.public.win32.programmer.networks)
  • Re: Socket overlapped I/O and FIONBIO
    ... is for the case you haven't set the socket in non-blocking mode. ... BSD socket approach. ... WSA_FLAG_OVERLAPPED that forces blocking mode. ... kernel completes if that will occur in fixed time. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Socket overlapped I/O and FIONBIO
    ... Non blocking mode demand overlapped mode too, so the socket will be ... even if socket itself is non-blocking ...
    (microsoft.public.win32.programmer.networks)
  • Re: Async socket & active connections
    ... The "blocking = true" in the disconnect phase seems to solve the ... Socket and TcpClient, ... blocking connection somewhere down the line. ... 300K connections, enough to start worrying... ...
    (microsoft.public.dotnet.languages.csharp)