Re: Close a blocked socket

Pete, interesting arguments. I am basically on the same path, except that I
took a different turn - you decided to go blocking, me - non-blocking, and
here is the funny part - for the same reason. I came to a conclusion, before
..NET, that non-blocking model is easier and should scale better, you decided
the other way.
But it may be easier for a programmer to conceptualize his i/o algorithm
by dedicating a thread or two to the socket i/o and using blocking
sockets.
I am running up to 30 simultaneous connections over the Internet and can
easily scale up to 100 or more if the needed. Poor men's IIS.

In .NET, the async use of Sockets is quite nice and, even more important,
scales very well due to its use of IOCP.
I am not impressed by .NET Socket class. I rewrote my servers and clients in
..NET, complete rewrite from Win32. I don't see any benefits on the socket
side except for the PR part (oh .NET, good). There is another thread today:
'BeginAccept Callback problem'. Touches on the problem with asynchronous
socket callbacks. Not much of a problem to worry about, except that under
Win32 it did not exist.

But my main point is that whatever one thinks about blocking versus
non-blocking, I really don't see how the question of whether a connection
can fail or not comes into it
Some connections will fail. If you are better of handling failed connections
(on both sides) using blocking sockets, then good for you. I have good
connection to the Internet on the server side. However, clients use laptops
on wireless lans. They shutdown their machines literally - fold the laptop
and walk out of the office. My servers handle it quite well. If I would
choose the blocking path, I would probably ruin the project.

Happy blocking, Michael

"Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx> wrote in message
news:op.tqk55ksh8jd0ej@xxxxxxxxxxxxxxxxxxxxxxx
On Tue, 10 Apr 2007 12:58:12 -0700, Michael Rubinstein
<mSPAM_REMOVEr@m®ubinstein.com> wrote:

Pete, my opinion is that blocking sockets should be used only when
there is a compelling reason for doing so.

I can agree with that. But "compelling reason" is in the eye of the
beholder.

I must admit, I can't name a single one.

Personally, I see no reason to not use blocking sockets if one is dealing
with a very simple situation (say, peer-to-peer application where you only
ever have one connection). Before .NET, using plain old Winsock, I would
extend this to be a simple situation in which there's no window message
pump, since WSAAsyncSelect is a pretty easy and convenient way to handle
socket i/o without adding a new thread.

In .NET, the async use of Sockets is quite nice and, even more important,
scales very well due to its use of IOCP. But it may be easier for a
programmer to conceptualize his i/o algorithm by dedicating a thread or
two to the socket i/o and using blocking sockets. It is much more
important for the code to be written correctly than for it to be written
using some particular paradigm, and if using blocking sockets advances
this goal of correctness, then it seems to me that's a good reason to use
blocking sockets.

In the simple scenario I mention above, I certainly see no real advantage
to using the Begin/End pattern over straight blocking sockets.

But my main point is that whatever one thinks about blocking versus
non-blocking, I really don't see how the question of whether a connection
can fail or not comes into it.

Pete


.

Relevant Pages

  • Re: Question on select() and sockets
    ... Making the sockets non-blocking guarantees control over when you block ... Although I was writing about pipes in my recent reply ... can still end up blocking, even if you only call reador write ...
    (comp.unix.programmer)
  • Re: blocking non blocking
    ... Ok now i am very confused...here is why i think non blocking is less ... non blocking sockets typically involve some busy waiting and ... somehow a server with 50K threads, ... or overlapped I/O servicing 50K clients. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Socket Send
    ... The sockets are blocking. ... Set the socket to non-blocking. ... I'm just curious as to what benefits reading a 4k block does? ...
    (comp.unix.programmer)
  • Re: blocking non blocking
    ... not connected to incoming data on the same thread, async sockets have to be ... somehow a server with 50K threads, ... or overlapped I/O servicing 50K clients. ... read and learnt about blocking and non blocking, ...
    (microsoft.public.win32.programmer.networks)
  • Re: Close a blocked socket
    ... which I believe blocking is fine, ... But if you are not using IOCP, then as you approach tens of thousands of connections, .NET Sockets will outperform a straight Winsock implementation. ... The exception that thread is complaining about is completely harmless, and is no different from any other informational exceptions that occur in .NET. ...
    (microsoft.public.dotnet.languages.csharp)
Quantcast