Forgot to cc tipc-dicussion... ///jon --- Jon Paul Maloy <[EMAIL PROTECTED]> a écrit :
> Date : Tue, 4 Mar 2008 11:20:50 -0500 (EST) > De : Jon Paul Maloy <[EMAIL PROTECTED]> > Objet: RE : [tipc-discussion] Link retransmission > implementation > À : [EMAIL PROTECTED] > > Regards > ///jon > > --- [EMAIL PROTECTED] a écrit : > > > Hi, > > > > though I read every documentation about TIPC that > I > > could find, I still have many unanswered > questions, > > especially about the implementation of reliable > > datagram communication (this is the only > > communication type we are currently using). Maybe > > you can help answering some of them: > > > > 1. Exactly how does a link detect a message loss > > that did not occur due to link congestion (e. g. > > lost in the switch)? Does the receiver send acks > or > > is the loss detected only by gaps in the serial > > number? > Both. The receiver sends an ack (a "link state" > message) every 16th received packets. This is more > for > flow control than for loss detection, but the > message > contains all info needed for possible retransmission > and detection of gaps. > > > > 2. Is a message automatically retransmitted if it > > gets lost and the reason is not a link congestion? > Yes. And even if the reason is link congestion. As a > user, link congestion isn't anything you need to > worry > about. > (However, I suspect that you really mean > "destination > overload" by this term, i.e. that a message may be > rejected at the receiving socket because of a too > slow > receiver. With RDM sockets you must always be > prepared > for that.) > > > > 3. When I send a message via an RDM link, does it > > get buffered somewhere till an ack has arrived (if > > acks are used, see 1.)? > Yes. In a configurable-size send queue per link. > > > > 4. If it gets buffered can it be accessed using > the > > internal API? > No. > > I'd like to give an example to this : I send a RDM > > message via the internal API, a link congestion > > occurs and the appropriate error handler is called > > with reason ELINKCONG. Now I'd like to retransmit > > this message. How can I accomplish this? > > As a user, you will never see an ELINKCONG. At link > congestion, the sending process is blocked until the > congestion has abated, and then the message is sent > automatically be the socket code. > > > > > 5. Is there a difference in error detection (i. e. > > lost messages) and retransmission between reliable > > datagrams and messages sent over a connection > > (assuming the DEST_DROPPABLE flag is not set on > the > > RDM socket)? > > No. It is the same mechanism. However, connection > oriented message are subject to a socket-to-socket > flow control that assures that you will never see a > message rejected due to destination socket overload. > > > > > Thx for any answers! > > > > Regards, > > J.K. > > > > > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio > > 2008. > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > 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 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
