socket hangs

[Alex]

Hi,

I am programming asynchronous communication between client and server,
with .net asynchronous sockets example from MSDN
(http://msdn.microsoft.com/library/d...e/html/cpconusingnon-blockingserversocket.asp)

The problem is that the application hangs on the client side, when the
server sends a buffer. It doesn't reach the read-callback (that is
assigned right after successful "Connect(server,port)") on the client
side, the app just hangs.

So: is a .net socket full-duplex, i.e. can it send and receive ?
When I the sockets are asynchronous, should the Blocking property be
set to false (since the documentation says it's true by default) ?

How can I debug the hanged app/machine to know what's really goes on,
and why the client is stuck ?

Any help would be appretiated!
Alex.

 

[Chad Z. Hower aka Kudzu]

(e-mail address removed) (Alex) wrote in

The problem is that the application hangs on the client side, when the
server sends a buffer. It doesn't reach the read-callback (that is
assigned right after successful "Connect(server,port)") on the client
side, the app just hangs.

Are you committed to async? Why not use synchronous?

So: is a .net socket full-duplex, i.e. can it send and receive ?
When I the sockets are asynchronous, should the Blocking property be
set to false (since the documentation says it's true by default) ?

It would seem so, because blocking = synchronous.



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com

 

[Alex]

(e-mail address removed) (Alex) wrote in


Are you committed to async? Why not use synchronous?

I don't want to manage a thread for each client, and,
generally, at least in MFC programming synchronous socket is an awful
idea.
There are really no synchronous sockets, and system.net socket uses
completion ports, which should make them fast enough for my needs. So,
I'll stick to asynchronous.

It would seem so, because blocking = synchronous.

Of course, but what is the difference in behaviour of asynchronous
socket with callbacks when blocking is set to true, versus false ? Do
you know ?

 

[Chad Z. Hower aka Kudzu]

(e-mail address removed) (Alex) wrote in

I don't want to manage a thread for each client, and,

It depends on what you are doing, but in most cases it makes things much
easier.

generally, at least in MFC programming synchronous socket is an awful
idea.

That is not true - this is very common misconception conceived early on in
the Windows 3.1 days.

There are really no synchronous sockets, and system.net socket uses
completion ports, which should make them fast enough for my needs. So,
I'll stick to asynchronous.

There are two types of async - the message based ones and the IOCP ones.
Direct IOCP writing creates spaghetthi bug prone code.

Except under the heaviest of loads you wont notice a difference, and a single
thread queing all responses will actually respond slower because it forms a
bottlenceck.

Of course, but what is the difference in behaviour of asynchronous
socket with callbacks when blocking is set to true, versus false ? Do
you know ?

Not in this case. MS doesnt give source to this stuff, which is a real shame.




--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com