Hi Felix: If you use connection-oriented communication between your clients and servers then TIPC will automatically block the client from sending messages to its server once more than about 1000 messages accumulate at the server end, which will help prevent a single non-responsive server from consuming too many resources. However, this really doesn't help a whole lot since it is still possible for multiple non-responsive servers to hog all of the allowable message buffers in their receive queues; nor does this help if you really need to use connectionless messaging.
So, at the moment, I think it's left up to the applications using TIPC to do the necessary work to ensure that they don't choke the system with too many messages. There has been some discussion on this mailing list over the last couple of years about what might be desirable to provide a better way of dealing with congestion and to provide better quality of service (QoS) characteristics (such as Randy's request to make the socket receive queue thresholds programmable), but so far no one has stepped forward to actually do any work in this area. -- Al -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nayman Felix-QA5535 Sent: Wednesday, May 30, 2007 2:27 PM To: Horvath, Elmer; Randy Macleod; Stephens, Allan Cc: [email protected] Subject: Re: [tipc-discussion] Dropped messages in TIPC 1.5.12 Guys, Thanks for the replies. What Al mentioned is exactly what's happening. The real issue from our product's point of view is to have a way to detect that we're in a congestion situation for either one socket or more importantly, per-node socket congestion. Is there a way to detect that this is happening? Thanks, Felix -----Original Message----- From: Horvath, Elmer [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 30, 2007 1:09 PM To: Randy Macleod; Stephens, Allan Cc: Nayman Felix-QA5535; [email protected] Subject: RE: [tipc-discussion] Dropped messages in TIPC 1.5.12 Hi, I would actually say that the data itself is more important than getting a message (that may or may not make it through to the sender depending on many factors). In that event, shouldn't the returned message be sent at: original importance - 1 Just playing devil's advocate. Elmer Randy Exclaimed: >Stephens, Allan wrote: >> Hi Felix: >> >> The results in case 1) are to be expected since you are running your >> client and servers on the same node. What is happening is that the >> messages to the server are still being rejected, but are not being >> queued up on the client's receive queue because this would exceed the >> 5000 message per node limit. (That is, the same mechanism that prevents >> the messages from reaching the servers also prevents them from returning >> to the client.) > Does this design seem reasonable? > Shouldn't message replies indicating: "I'm full/busy" be sent at: > original importance + 1 > // Randy I would actually say that the data itself is more important than getting a message (that may or may not make it back to the sender depending on many factors). In that event, shouldn't the returned message be sent at: original importance - 1 Just playing devil's advocate. ;) Elmer > > The results in case 2) probably make sense for the same reason. What is > probably happening here is that messages are rejected by one of the > servers once it's queue reaches 2500, but before the other server's > queue has reached that limit; consequently, some rejected messsages make > it back to the client and are consumed, allowing things to continue > until the clients have sent 12000 messages. However, once both servers > reach the 2500 message limit, the scenario becomes identical to that in > case 1) and no further rejected messages are received by the client. > > Regards, > Al > > ------------------------------------------------------------------------ > *From:* [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] *On Behalf Of > *Nayman Felix-QA5535 > *Sent:* Wednesday, May 30, 2007 12:14 PM > *To:* [email protected] > *Cc:* Horvath, Elmer > *Subject:* [tipc-discussion] Dropped messages in TIPC 1.5.12 > > Since I didn't get a response to my previous post, I'll try to make this > post easier to read and answer. > > I've noticed two things while running various congestion tests where a > server is not pulling messages off of its receive queue: > > 1)When I reach the 5000 per node socket-based congestion limit after > doing the following: > a)running one server/client pair and filling up that server's receive queue > b) then start a second server and fills up its receive queue using the > same client > c)messages are no longer rejected back to the client once I reach the > 5000 message count, instead they appear to be just dropped. Is that > behavior expected? > > 2)When I've got 2 servers running without pulling messages off of their > receive queue (regardless of whether or not they have the same TIPC > Name). I see no rejections whatsoever after sending over 12000 > messages. The messages appear to just get dropped. Why? > > I'm running TIPC 1.5.12 on a 2.6.9 linux kernel with connectionless > traffic on the same node with the domain set to closest first and the > destination droppable flag set to FALSE. I'm running modified versions > of the hello world demo client and server programs for this testing. > > Let me know if you need anymore information. > Thanks in advance, > Felix > ------------------------------------------------------------------------ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion ------------------------------------------------------------------------ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
