Hi Jon > This doesn't make sense to me. To reach the global limit of 5000 messages > Allan is mentioning, you must have at least two open connections, and flood > both with 2500 unread messages. > > Can you confirm that this is what is happening, Bharat? >
Yes. I asked this because I wanted to know that it has been implemented like this intentionally and now I understand the reason as well. I would like to thank all of them who responded. Regards, Bharat > If you only have one connection, it should *never* be aborted because of > overload. Instead, the sending process should be blocked until the receiver > has read enough messages, just as you would expect. > > If not, there is either a bug somewhere, or a misunderstanding of what you > are trying to do. > > ///jon > > Bharat Joshi wrote: > > Hi Allan, > > > > > >> TIPC currently *does* have a mechanism in place to allow a congested > >> receiver to provide back pressure to its connection-oriented peer, > >> thereby automatically blocking the peer from sending additional messages > >> until the receiver begins consuming messages. A connection-oriented > >> sender keeps track of the number of messages it has sent to the > >> receiver, and also records acknowledgements from the receiver as to how > >> many messages it has consumed; the difference between the two is the > >> number of "sent, but not acknowledged" messages, and reflects the > >> sender's view of the size of the receiver's receive queue. If this > >> value reaches 1024, TIPC should block the sender automatically until > >> more acknowledgements are received. > >> > > > > Yes. I see this mechanism and unfortunately it does not work for my > > case. In my case, receiver is not reading its receive queue and its > > receive queue gets filled so in this case, I do not want it to tear > > down the connection but just block the sender till there is space > > available in the receive queue. The issue here is that the > > receive-queue of the socket is not big enough to hold that many > > packets. > > > > Anyway thanks for the reply. > > > > Thanks, > > Bharat > > > > > >> Now, I can think of at least one way where this flow control mechanism > >> can be circumvented (and there may be more). It could be that the > >> receiver begins rejecting messages because TIPC's global socket queue > >> limit has been reached (meaning there are at least 5000 messages waiting > >> on all socket queues taken as a whole), rather than because its own > >> receive queue has reached the per-socket 2500 message limit normally > >> required to trigger rejection. > >> > >> Does this seem to be a likely scenario for your system? > >> > >> Regards, > >> Al > >> > >> > >> > >>> -----Original Message----- > >>> From: [EMAIL PROTECTED] > >>> [mailto:[EMAIL PROTECTED] On > >>> Behalf Of Bharat Joshi > >>> Sent: Wednesday, November 14, 2007 10:07 AM > >>> To: Horvath, Elmer > >>> Cc: [email protected] > >>> Subject: Re: [tipc-discussion] Query on the overloading of a receiver > >>> > >>> 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 > >>> > >>> > > > > ------------------------------------------------------------------------- > > 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
