Strange server socket behaviour

[Massimo]

This is why I suspect the problem is with mixing the asynchronous and
synchronous models for this class. The documentation is not entirely clear
about what goes on underneath, and one would need a network protocol
analyzer to be entirely sure, but knowing Microsoft, the 2 models
(synchronous and asynchronous) were designed as the documentation
suggests, each to work within the parameters of that model. So, before I
tried to do all of that packet analysis, I would simply try the easiest
method and switch to a consistent usage of the object model, which
Microsoft probably tested fairly well, just to potentially save time.

To be absolutely sure this wasn't the reason for the error, I replaced the
Receive() call with a BeginReceive() one.
As expected, nothing changed: the same exception is thrown.


Massimo

 

[Peter Duniho]

This is why I suspect the problem is with mixing the asynchronous and
synchronous models for this class. The documentation is not entirely
clear
about what goes on underneath, and one would need a network protocol
analyzer to be entirely sure, but knowing Microsoft, the 2 models
(synchronous and asynchronous) were designed as the documentation
suggests,
each to work within the parameters of that model.

While there's nothing wrong with the general line of your thinking, in
this case it leads to the wrong conclusison. There's nothing
fundamentally wrong with mixing blocking and non-blocking or synchronous
and asynchronous paradigms in this case. That is, the .NET sockets are
simply built on top of Winsock and there's nothing wrong in Winsock with
accepting using a blocking/synchronous call but using a non-blocking/async
paradigm to receive data.

Pete

 

[Kevin Spencer]

Tht's a good thing. It means the (managed) software was not only designed as
it should be, but tested with the various possible combination scenarios.
Still, without knowing for sure what is inside the black box, I would have
given this a try first, in the interest of expediency. Debugging via packet
sniffing is certainly thorough, but more time-consuming.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer
http://unclechutney.blogspot.com

The shortest distance between 2 points is a curve.

 

[Goran Sliskovic]

Can you elaborate about this, or give me some links to more info?


Massimo

It's just a thought... I suppuse you receive RST segment, becuase error is
WSEACONRESET. This is probably cuased by client calling close on socket.
When TCP stack receives RST, it will discard any pending (not removed from
read buffer and not sent) packets and signal WSEACONRESET on all subsequent
operation (read & write). So even if incoming data is already buffered, recv
will return that error. But it's hard to tell without actually seeing the
trace/client source.

Check:
http://groups.google.hr/group/micro...+receive+buffer&rnum=8&hl=hr#f7674d05ed602d8c

Regards,
Goran

 

[Massimo]

It's just a thought... I suppuse you receive RST segment, becuase error is
WSEACONRESET. This is probably cuased by client calling close on socket.

The problem is, the client isn't doing any Close() at all!
It just does Connect() (in its own way) and sits there waiting for the
connection to be established. At this point, the server's EndAccept()
triggers, the new socket is istantiated, and then the server does Receive(),
waiting for some data to be sent from the client. Now the client should
complete its Connect() succesfully... but it never does. It neither logs an
error: the Connect() never returns. But the server gets a SocketException
from its Receive(), saying the connection was closed by the client.
Absolutely ugly :-(


Massimo

 

[Goran Sliskovic]

....

The problem is, the client isn't doing any Close() at all!
It just does Connect() (in its own way) and sits there waiting for the
connection to be established. At this point, the server's EndAccept()
triggers, the new socket is istantiated, and then the server does Receive(),
waiting for some data to be sent from the client. Now the client should
complete its Connect() succesfully... but it never does. It neither logs an
error: the Connect() never returns. But the server gets a SocketException
from its Receive(), saying the connection was closed by the client.
Absolutely ugly :-(

....

Is that some kind of routed network/dialup?

Goran

 

[Massimo]

Is that some kind of routed network/dialup?

See the original post for details.


Massimo

 

[Goran Sliskovic]

See the original post for details.

....
Ah, sorry, it was few days ago. It's hard to tell without the actual packet
trace, but it maybe the problem with routing. Since client never finishes
connect, but server receives connection, there may be problem for packets
from server reaching client (NAT, firewall, routes). I'm not sure though
when accept event is signal on socket, when SYN packet is received or when
3-way handshake has completed. Anyone?

Regards,
Goran

 

[Massimo]

...
Ah, sorry, it was few days ago. It's hard to tell without the actual
packet
trace, but it maybe the problem with routing. Since client never finishes
connect, but server receives connection, there may be problem for packets
from server reaching client (NAT, firewall, routes). I'm not sure though
when accept event is signal on socket, when SYN packet is received or when
3-way handshake has completed. Anyone?

The problem can have many different causes, and I actually think the
device's TCP/IP implementation is quite buggy. But my main concern is: why
can it connect succesfully to any Internet server but not to mine?


Massimo

 

[Massimo]

This code works perfectly when the client is a .NET program, but crashes
when a connection is made by the "real" client. A SocketException is
thrown during the first clientsocket.Receive(), complaining about the
connection being forcibly closed by the remote host. But the worse is
still to come: after this error (and the subsequent clientsocket.Close()),
serversocket.BeginAccept() too throws an exception!

The client, of course, didn't close anything... or at least didn't want
to. I think there must be some nasty bug in the client's TCP/IP libraries,
because the server works flawlessly with a .NET client... but, as I said,
the clients seem to work ok when connecting to other network servers, so
maybe the problem's here and I'm not correctly handling some error that
usually doesn't happen but sometimes do.

What can I do to understand what's really happening here?

Turned out it wasn't either the server or the client's fault, but mine :-(

I was using the wrong GPRS APN, and the one I was using could be used only
for WAP connections... so it silently truncated every connection going to a
TCP port different from 80. That was the reason the connection was being
focibly closed as soon as it was established.


Massimo