socket hangs

  • Thread starter Thread starter Alex
  • Start date Start date
A

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.
 
(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.
Click to expand...

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) ?
Click to expand...

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
 
Chad Z. Hower aka Kudzu said:
(e-mail address removed) (Alex) wrote in


Are you committed to async? Why not use synchronous?
Click to expand...

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.
Click to expand...
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 ?
 
(e-mail address removed) (Alex) wrote in
I don't want to manage a thread for each client, and,
Click to expand...

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.
Click to expand...

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.
Click to expand...

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 ?
Click to expand...

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
 
Back
Top