NetStream issues

[RobRasti]

I've got a handheld application that is sending and receiving data
over a NetworkStream. The physical connection to the server is either
a dialup modem or ActiveSync to a PC connected over VPN to the host
system.

Because of past performance issues there is an application level
protocol being used where in the Sender will send an XML message with
a unique ID and the Receiver will acknowledge that message by sending
back the unique ID.

The problem I am having is the following:

Handheld sends an Authentication request
Server responds with the proper acknowledgment

Server then validates the handheld and sends back further directions
Handheld responds but the Server never gets the acknowledgment

The Handheld does indeed get the further directions because it
continues on the processing as though nothing happened. However the
Server encounters a timeout waiting for the acknowledgment.

The handheld, as part of the normal processing receives the message
and closes the NetworkStream. Is there a chance that I am closing the
network stream before it has a chance to get the message out?

-R-

 

[Paul G. Tobey [eMVP]]

Capture the actual packets going out on the wire and see what's happening
(use a network sniffer of some sort, either an external instrument or a
sniffer piece of software that you can install on a PC).

I can't think of anything, other than an error in your coding, that would
cause data that is ready to be read not to be read. However, you might see
that the data sent in two separate write operations is actually going out in
a single packet. The network stack does that automatically to minimize the
bandwidth used for sending small messages.

Paul T.

 

[RobRasti]

Follow up question here.

I've just noticed this in some TCP packet traces using WireShark. The
handheld requests a connection with the server (SYN Packet) the server
acknowledges (SYN, ACK packet) and the handheld acknowledges (ACK
packet) which from what I have read is how it should be. Then I start
to see my XML data going back and forth as expected. Then it comes to
the disconnect, and that is where it looks odd to me. The Handheld
sends the last of its data to the server and the server responds with
a FIN, ACK packet. The handheld then responds with an ACK packet.
The Handheld then sends a FIN, ACK packet and the server responds with
an ACK and the handheld sends back an RST packet.

Is this normal? I currently have both sides of this application
requesting a disconnect on the network stream. Should I only be doing
that on one side?

Thanks for your help.

-Rob-

 

[Paul G. Tobey [eMVP]]

The server side is breaking the connection, sending the FIN packet (clean
shutdown of the connection). As to why, I couldn't say, other than that you
are doing that in your code. Yes, it's normal for the client to then reply
with FIN, also, before finally breaking the connection completely with the
RST packet. I can't tell you what you should do. If the server and the
client are both done with the connection, yes, they should close the socket
and, in the case of the server, presumably return to listening for new
connections.

Paul T.

 

[RobRasti]

Additional information on the "Disconnect" command I referenced.

The Disconnect is comprised of two steps.

tcpClient.Close();
netStream.Close();

Does calling these two commands back to back cause the port to close
prematurely and possibly cause my timeouts on the other end?

Thanks again for your help.

-Rob-

 

[Paul G. Tobey [eMVP]]

I never use TcpClient. The help for TcpClient.Close(), however, shows the
stream always being closed before the client is closed. If it were me, I'd
dump TcpClient and connect the sockets myself. That gives you proper
control over what's going on and you don't think about stream interfaces,
just reading and writing directly to the socket instance.

Paul T.

 

[Simon Hart [MVP]]

As Paul says, lose TcpClient instead use the Socket class, then if you have
coded it correctly more than likely you're problems will go away. Failing
that, post the relevant code here.