Hi,

icehong wrote:
> Thanks for your answer.
>  
>   But why reliable socket service must be on connection?    I didn't set
> TIPC_SRC_DROPPABLE option , but set TIPC_DEST_DROPPABLE and no use .

TIPC guarantees node to node (OS to OS) delivery by forming
a software link between nodes that owns a retransmission queue.
If packets are dropped by the network, then they will be retransmitted.

Now what happens when packets get to the far end and they can't be
consumed as quickly as they are being delivered? They'll queue up.
Clearly you don't want this recv socket queue to grow without a
limit so you either drop the packet or return it to the sender
depending on the user's stated options. In your case you only
care about the reliable option so let's consider what happens
when packets are returned to the sending node.

I suppose the returning packet(s!) could be inserted into
the retransmission queue but that would penalize other
processes sending to the same node that are well behaved.

The other alternative is to create a queue on the sending side
specifically to store the packets that have been rejected.
Once you have that connection queue or state, it's easy to
block the process that owns the connection until the far
end is ready to receive more data.

What I've just described is a connection-oriented socket.
Does that help?

>    Is there any socket option that support reliable packet deliver
> on connectioness socket ? */ /*

If you want to continue to use connectionless sockets, you
can create the connection object in **user-space** with a fairly
simple windowing protocol (send acks back on a dedicated
channel every N packets). This approach is a hack that
can help but requires knowledge of TIPC internals and
overall system behaviour (number of processes and sending rates)
in order to be robust - better to go connection-oriented usually.

// Randy




-------------------------------------------------------------------------
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

Reply via email to