S
Slappy White
Hi All,
I have a strange problem with .net sockets (Protocol TCP/IP). I have
developed a slave application that listens for incoming connection in
asynchronous mode, and accepts incoming connection in a socket and returns
to the listening mode.
The connected socket then uses async mode to read and write from the
underlying network stream. In the AsyncRead call back function an event is
raised to handle the data received. While processing the message, If the
break the connection from my master application (which sends data), none of
the async read/send call back methods throws an exception to indicate
connection is broken.
The worst is when I send the Ack, the properties of socket indicate the
stream is connected and the async send method sends data without any
throwing exception. But, I know for sure connection is broken. This puts my
messaging processing system in soup.
The big issue for me here is that I have invested a great deal of time and
an important client's money developing this solution. I chose .Net because
of it's reputation as a cutting edge server based framework and convinced my
client this was the way to go. Now I find that the solution is unusable and
I have been let down by the .Net framework. This is a critical system and a
socket sending an acknowledgement to a non-existent connection and reporting
success is frightening in terms of the undependability of this component of
the .Net Framework.
Is there an answer to this problem? Is there a fix for what is undeniably a
massive bug in the Socket class? How can I proceed using my solution in
..Net?
Is there an alternative third party socket class (similar to winsock
control) that I can use to solve this problem?
Any help is greatly appreciated.
Thanks & Regards,
An extremely disappointed dotnet framework user.
I have a strange problem with .net sockets (Protocol TCP/IP). I have
developed a slave application that listens for incoming connection in
asynchronous mode, and accepts incoming connection in a socket and returns
to the listening mode.
The connected socket then uses async mode to read and write from the
underlying network stream. In the AsyncRead call back function an event is
raised to handle the data received. While processing the message, If the
break the connection from my master application (which sends data), none of
the async read/send call back methods throws an exception to indicate
connection is broken.
The worst is when I send the Ack, the properties of socket indicate the
stream is connected and the async send method sends data without any
throwing exception. But, I know for sure connection is broken. This puts my
messaging processing system in soup.
The big issue for me here is that I have invested a great deal of time and
an important client's money developing this solution. I chose .Net because
of it's reputation as a cutting edge server based framework and convinced my
client this was the way to go. Now I find that the solution is unusable and
I have been let down by the .Net framework. This is a critical system and a
socket sending an acknowledgement to a non-existent connection and reporting
success is frightening in terms of the undependability of this component of
the .Net Framework.
Is there an answer to this problem? Is there a fix for what is undeniably a
massive bug in the Socket class? How can I proceed using my solution in
..Net?
Is there an alternative third party socket class (similar to winsock
control) that I can use to solve this problem?
Any help is greatly appreciated.
Thanks & Regards,
An extremely disappointed dotnet framework user.