Hi Bharat, The behaviour you have observed is the way that TIPC handles a full queue. It is difficult to distinguish between an application that has simply gone to do something else for a while (allowing the queue to fill) and one which has died and will never come back to process its queue.
Your suggestion is interesting and with merit depending on the application. Since you are using stream sockets, the only thing that pops to mind is to do what you suggest but at the application level. Ie, have the client send some sort of application level acknowledgement that it is processing data and use this to sychronize the transmission of data to it to keep the queue sizes reasonable. In this way, only those applications that need this functionality would use it and the TIPC code base would remain uncluttered and not have to try to distinguish between a slow and a dead application receiving data. Maybe others have other suggestions for you. Elmer -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bharat Joshi Sent: Wednesday, November 14, 2007 4:47 AM To: [email protected] Subject: [tipc-discussion] Query on the overloading of a receiver Hi, I have a Stream Socket client-server application using TIPC socket. Both client and server run on the same node. After client connects to server, server start sending 1kB data to the client. I see that if clients receive queue is full, we return an error TIPC_ERR_OVERLOAD through reject-message. This results in the server tearing down the connection. Should not server wait for the client to process all its messages and when it can accept more messages, it can ask server to send more messages. Is this behavior correct? Thanks, Bharat ------------------------------------------------------------------------ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
