See below. Regards ///jon
[EMAIL PROTECTED] wrote: > > I think you got me wrong on this one. I know the mechanism when sending a > message from userspace, but in my example I sent it from within the kernel > using the native API Ok, that explains it. > (I called it "internal API" by mistake). If sending the message succeeds but > it can't be delivered at the receiving node because of a link congestion (you > called it "destination overload"), the appropriate err_event_handler at the > sending node is called with reason ELINKCONG (if the DEST_DROPPABLE flag has > been unset). As a native API user you actually _get_ an ELINKCONG as return value of your send call, in case of link congestion. Then you can keep your message and send it later, i.e., when you receive a tipc_continue_event. This callback indicates that the link congestion has abated. The error handler is only used when the message was truly undeliverable, e.g. because the link went down, the destination port or processor disappeared, or because the reception queue in the receiving socket has overflowed. The latter can only happen if the receiver is a socket, of course. If it is also an application in kernel space, you control this yourself, by making your own flow control. If you want a flow control even when the receiver is a user space app with a socket API, you will have to set up a connection. Then, you will get an ELINKCONG returned even in this case, and can handle it the same way as a link congestion. > In this case, I'd like to retranmsit the message from within the > error-handler. But, as far as I know, only the first 1024 are returned and > accessible using the "unsigned char* data" pointer given to the > event-handler. How can I access and retransmit the WHOLE message? > I thought that would happen automatically when using connected communication > from userspace, but I figured out (looking at the source code) that the TIPC > socket implementation does not make use of event_handlers at all. So what > happens in case of a destination overload when using conntected communication? > This is handled. Look at "wakeupdispatch()' in tipc_socket.c, it _is_ and eventhandler, which in the case of the native API calls tipc_continue_event. > > ------------------------------------------------------------------------- > 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
