Hi Felix, See inline below. Elmer
> -----Original Message----- > From: Nayman Felix-QA5535 [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 30, 2007 4:51 PM > To: Stephens, Allan; Horvath, Elmer; Randy Macleod > Cc: [email protected] > Subject: RE: [tipc-discussion] Dropped messages in TIPC 1.5.12 > > Thanks for the response. Unfortunately, I don't think its > feasible for > us to use connection-oriented messaging > > A related question. What, if any, are the drawbacks or performance > issues to increasing the importance level of a socket to medium, high, > or even critical from low? Using a high level of importance will allow more messages to be sent and queued on various sockets. The positive impact will be that more of your messages will get through. The negative impact will be a higher usage of resources and you may end up starving out other sockets from queuing messages. > After looking through the programmer's guide again, I think > the section > on message consumption and rejection with regards to reaching the > per-node socket congestion limit is misleading. From a strict reading > of those sections, it would appear to me that if the destination > droppable setting is disabled, TIPC should send that message > back to the > sender (and in a sense I guess it is). Maybe this calls for a note to > clarify this situation and say that if the per-node socket congestion > limit has been reached, the message shall just be dropped because it > cannot be put on the original sender's receive queue. You may have a point here. The documentation does state (under the "THINGS TO REMEMBER:" section in Message Rejection) that "the non-return a message does not indicate that is was successfully consumed". So the application must be able to handle not getting a returned message even when things go wrong. > Is there something wrong with the tipc-discussion list? I > keep getting > Internal Server errors while trying to access various > postings and it is > otherwise very slow and has been this way for at least the past few > days. Also, the link from http://tipc.sourceforge.net/support.html to > view archived postings is broken. I also got an error just now. Not sure what is up there. > Thanks, > Felix > > > -----Original Message----- > From: Stephens, Allan [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 30, 2007 3:21 PM > To: Nayman Felix-QA5535; Horvath, Elmer; Randy Macleod > Cc: [email protected] > Subject: RE: [tipc-discussion] Dropped messages in TIPC 1.5.12 > > 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
