Hi Elmer,
Thanks for your reponse. Please see my reply in line.
Regards,
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.
>
But I guess if the process dies, socket would be closed and socket
receive queue won't be there. Right?
> 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.
>
But why do not we add this in TIPC itself? I would say that if receive
queue is full, we send OVERLOAD message back to the sender, sender
should see this as port-congestion and sleep. Now when receiver read
some message, it invokes tipc_acknowledge() and this will send a
proto-msg to other end, which will wakeup the sender.
Why I raised this in the mailing list is because I wanted to know why
TIPC does not behave this way?
> Maybe others have other suggestions for you.
Will wait for other reply as well.
> 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
