Networkstream.write does not throw IOException

  • Thread starter Thread starter Carla
  • Start date Start date
C

Carla

Hello All,

I found similar questions but no answers., please advise -

I use a TCPClient for sending data to a TCPServer.
The client opens a connection using the TCPClient class & sending using
the Networkstream class's write method. The server was written in c.
It all goes well.

The problem occurs when the server goes down (closes the socket), then
the write should throw an IOException, but in fact, it throws an
exception only on the second call to write.
(this means I lose the first buffer ...)
I tried to set the NoDelay prop of the TCPClient to yes,
and the SendBufferSize to the exact buffer size I'm sending (~160).

thanx ahead
 
Hello, Carla!

C> I use a TCPClient for sending data to a TCPServer.
C> The client opens a connection using the TCPClient class & sending using
C> the Networkstream class's write method. The server was written in c.
C> It all goes well.

C> The problem occurs when the server goes down (closes the socket), then
C> the write should throw an IOException, but in fact, it throws an
C> exception only on the second call to write.

What is in the value of InnerException property of that IOException?

C> (this means I lose the first buffer ...)
C> I tried to set the NoDelay prop of the TCPClient to yes,
C> and the SendBufferSize to the exact buffer size I'm sending (~160).

Does your TCPClient operate in synchronous mode or asynchronous?

--
Regards, Vadym Stetsyak
www: http://vadmyst.blogspot.com
 
Hi Vadym,

well, the inner exception is a SocketException (it's on the second
Write call...)
and the message says
"An established connection was aborted by the software in your host
machine".

I'm using synchronous mode.
 
Hello, Carla!

C> well, the inner exception is a SocketException (it's on the second
C> Write call...)
C> and the message says
C> "An established connection was aborted by the software in your host
C> machine".

C> I'm using synchronous mode.

Looks strange...

When you issue first send ( Write ) is remote server online, or it is already "down"?
Generally in sync mode Write or Socket.Send call block until data is transferred and ACKed.

IMO the situation you observe could have happened because remote server actually received first data portion.
You can try to figure this out using network sniffing tool. ( Ethereal or Network Monitor )

--
Regards, Vadym Stetsyak
www: http://vadmyst.blogspot.com
 
Carla said:
Hello All,

I found similar questions but no answers., please advise -

I use a TCPClient for sending data to a TCPServer.
The client opens a connection using the TCPClient class & sending using
the Networkstream class's write method. The server was written in c.
It all goes well.

The problem occurs when the server goes down (closes the socket), then
the write should throw an IOException, but in fact, it throws an
exception only on the second call to write.
(this means I lose the first buffer ...)
I tried to set the NoDelay prop of the TCPClient to yes,
and the SendBufferSize to the exact buffer size I'm sending (~160).

thanx ahead
Click to expand...

Hi,

This is by design. When you call send, OS buffers the data and returns
immediatly. Then in the background, OS tries to send that data. There is no
immediate notification of failure, if connection has gone down you'll be
notified on next socket operation (read or write). It is up to application
to implement session control. When send succeds, it DOES NOT mean that data
is received by other side, it means only that it is buffered by the OS. It
may be or may not be delivered.

Regards,
Goran
 
it is strange,
I double checked it, and you were right (!) it is something in the
server.
my OS is win 2003 & my server is a console application.
when I kill the server's process from the taskmngr I get the exception
in the client.
but when I close the console and make sure it does not appear in the
task manager (I have a close socket in the onCloseConsole callback) I
don't get the exception in the client.
I have no idea what's the difference...
but at least I know it is not in the client.
thanks!
 
Goran please see my bellow message - reagrding killing the server
process.
what's the difference between killing it straight from the taskmanager,
or closing the console window untill it disappears from the
taskmanager?
is it possible that when killing it the OS closes directly the socket
and when closing it it waits for some timeout?
 
Goran please see my bellow message - regarding killing the server's
process.
what's the difference between killing it straight from the taskmanager,
or closing the console window untill it disappears from the
taskmanager?
is it possible that when killing it the OS closes directly the socket
and when closing it it waits for some timeout?
 
Carla said:
Goran please see my bellow message - reagrding killing the server
process.
what's the difference between killing it straight from the taskmanager,
or closing the console window untill it disappears from the
taskmanager?
is it possible that when killing it the OS closes directly the socket
and when closing it it waits for some timeout?
Click to expand...

Hi,

Shutdown/disconnect procedure is rather complex. There is an article in MSDN
about shutdown, linger options etc:

http://msdn.microsoft.com/library/d...cmxspec/html/vcmanagedextensionsspec_20_1.asp

There may be differences between application closing socket and system
closing socket when process terminates.
You may that data is received by other side. I tested with TCP client and if
I disconnect the cable, send succeeds (be sure to disconnect other never
assume that because send succedeed computer from switch, not one running
client, because windows will reset all connection when detectes that
media/cable is down). Then TCP retransmission kicks in the background. After
that time expires (about 1 min in average setup), next send or receive call
will fail (because there is no asynchronous notification of connection going
down). But you cannot know whether first send went through or not.

When TCP protocol has received notification that connection is down, only
then will next send/receive fail. Please also note that there is no
information exchange on idle socket. If you issue blocking receive call
without timeout and disconnect cable from other computer, that call will
block forever (unless TCP keepalive option is set, in which case it may
detect connection is down).

Regards,
Goran
 
....

Argh, managed to sramble the text (unintentional select/move). Here it is
again:

Hi,

Shutdown/disconnect procedure is rather complex. There is an article in MSDN
about shutdown, linger options etc:

http://msdn.microsoft.com/library/d...cmxspec/html/vcmanagedextensionsspec_20_1.asp

There may be differences between application closing socket and system
closing socket when process terminates. You may never assume that because
send succedeed that data is received by other side. I tested with TCP
client and if I disconnect the cable, send succeeds (be sure to disconnect
other computer from switch, not one running client, because windows will
reset all connection when detectes that media/cable is down). Then TCP
retransmission kicks in the background. After that time expires (about 1 min
in average setup), next send or receive call will fail (because there is no
asynchronous notification of connection going down). But you cannot know
whether first send went through or not.

When TCP protocol has received notification that connection is down, only
then will next send/receive fail. Please also note that there is no
information exchange on idle socket. If you issue blocking receive call
without timeout and disconnect cable from other computer, that call will
block forever (unless TCP keepalive option is set, in which case it may
detect connection is down).

Regards,
Goran
 
Back
Top