Stuck in stream.read ... plz help.

[mulham.haffar]

hi guys..
im writing an application that uses windows service to listen (as a
tcplistener) for any data sent (by a tcpclient) ...
one kind of the requests might be a file sent by client and the service
should recieve it as number of packets.
the problem is: in the windows service when it detects that the data
coming is a file it make a loop (which equals the number of packets the
client will send the file by it, which will be determined by the first
packet.)
BUT.. if the client (for some reason didnt send that number..) just
sent a less then the windows service got crazy!! will stuck at the line
" stream.read waiting for remaining packets.
is there a way that i can cancel the read after some timeout and let
the service continue the flow ??
thanks in advance.

 

[Frans Bouma [C# MVP]]

hi guys..
im writing an application that uses windows service to listen (as a
tcplistener) for any data sent (by a tcpclient) ...
one kind of the requests might be a file sent by client and the
service should recieve it as number of packets.
the problem is: in the windows service when it detects that the data
coming is a file it make a loop (which equals the number of packets
the client will send the file by it, which will be determined by the
first packet.)
BUT.. if the client (for some reason didnt send that number..) just
sent a less then the windows service got crazy!! will stuck at the
line " stream.read waiting for remaining packets.
is there a way that i can cancel the read after some timeout and let
the service continue the flow ??

Always write these kind of services with a subsystem. You have a
listener thread which accepts connections from clients. Once a client
connects, the listener thread spawns a new instance of the subsystem
and hands the subsystem the connection. The subsystem is thus a new
thread. The listener thread then goes back to listening.

The subsystem starts starts reading data as it rolls in from the
client. After every packet read it starts a timer. If the next packet
doesn't come in before the timer ends, the subsystem aborts the
connection due to a timeout and ends itself. If the next packet does
arrive before the timer, it simply disables the timer and reads the
packet.

It's generally not a good idea to send the # of packets up front,
except if you're not using it to allocate a buffer. Never use the # of
packets send to allocate a buffer, as a malicious hacker dan send a
very large number to your service and it will crash.

FB

--