asked on

TCustomWinSocket Send Error Problems

I've got a multithreaded Borland Builder C++ service application that normally runs on a NT 4 Server that has major problems when one of the sockets encounters a send error. The application uses a TServerSocket (Non-Blocking) as a listening socket that spawns TCustomWinSockets (also Non-Blocking) and processing threads upon connection (multiple connections from various clients possible). The threads are TThreads and are spawned and shutdown manually rather than with the TServerSocket component. All socket communication is currently handled within the main application thread and the data is buffered to the processing threads and safteyed using critical sections (there is no VCL component access from within the threads). All works well until one of the TCustomWinSockets encounters a Send error (ErrorEvent == eeSend / 10053). The socket disconnects as advertised and sets the Disconnect error and event and then it seems that all of the open TCustomWinSockets remain open but they appear to stop sending and receiving (or at least they don't trigger the events) and further connections are not possible although the listening socket is still active. The application doesn't lock up nor do the threads however, the service won't stop and the entire server must be rebooted before the application will run again. No Exceptions are noted in the logs however I do trap the socket error exception and attempt to deal with it (obviously not very well in this case :). Try/Catch on the Socket->SendText or Socket->Sendbuf do not display any triggered exceptions. This does not happen on Disconnect errors and I haven't encountered any of the other socket error types to know whether they cause the same problem or not. I'd like to keep the sockets async and have tried both Socket->SendText and Socket->Sendbuff with some monitoring. I've also tried placing the socket read/write routines inside of TThreads and using Synchronize with no success - same problem exists. Is there some type of cleanup on the TCustomWinSocket component or socket itself that needs to be performed when a send error is recieved? A lot (tons) more details available if needed. Any help or ideas appreciated.

Thanks,
Greg

tosch

> The application uses a TServerSocket (Non-Blocking) as a listening socket that spawns TCustomWinSockets (also Non-Blocking) and processing threads upon connection (multiple connections from various clients possible).

multiple connections from various clients can also be achieved using the ThreadBlocking mode. is this the reaseon for you to use non blocking io ?

non blocking io is harder to deal with - more error prone, less efficient and not required to allow concurrent client connections.
you should not use it unless it is really needed.

what you are doing sounds very complicated to me.

if you use the ThreadBlocking mode you still have to manually spawn the thread, but there is a special thread class called TServerClientThread whose instances can be cached by the TServerSocket component (there is the property KeepInCache to enable/disable caching).
you'll have to create this in the OnGetThread event.

i won't go into further detail because the online help is quite good about that.
if you want i can mail you a source of a simple server capable of handling multiple clients at once.

gament

ASKER

Thanks Tosch. Actually I had originally used ThreadBlocking and had some problems with the events and changed it to async. I'll be the first to admit though that I probably didn't spend the time needed to dig into it. This comment in the help scared me off since I didn't have the time to mess with it -- I went async instead:

Applications that receive frequent client requests will want to derive a descendant class from TServerClientThread to handle reading and writing to separate clients. This is because TServerClientThread objects use the OnClientRead and OnClientWrite events of the associated server socket. These events are not thread-local.

I would appreciate the email with the sample you mentioned. greg@amentfamily.net -- thanks :)

I did come to another conclusion this morning with this problem - it almost appears that the send error is generated because the socket was closed when the data was sent. This could only happen if winsock closes the socket and I send the data before the component is updated to show the disconnect because I check for Socket->Connected just prior to sending..

Tnx,
Greg

gament

ASKER

ASKER CERTIFIED SOLUTION

tosch

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

udil

This question has been abandoned. I will make a recommendation to the moderators on its resolution in a week or two. I appreciate any comments that would help me to make a recommendation.

In the absence of responses, I may recommend DELETE unless it is clear to me that it has value as a PAQ. Silence = you don't care

PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!

Udil
EE Cleanup Volunteer

Kyle Abrahams, PMP

No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:

Grade B to tosch

Please leave any comments here within the next seven days.

PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!

Ged
EE Cleanup Volunteer

tosch

My program I cut the posted code from is working well with several clients.
I am really interested if it was of any help, though.