[tipc-discussion] About SOCK_RDM socket
Hi ,
I write a sample test routine and want to test a SOCK_RDM socket tipc
socket,
The server routine receive packets and then drop it , then sleep for 10
ms ,
while (1) {
recv the packet ;
usleep 1 ;
}
and the client send packets continously, I think when the receive buffer
is full, the client should be blocked. But the result is the client
continously send the packets. I found same packets were lost after a few
minutes.
from linux man page :
SOCK_RDM Provides a reliable datagram layer that does not guarantee
ordering.
Am I misunderstanding the documents or it's a bug of tipc ?
Thanks for your help,
icehong
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] About SOCK_RDM socket
Hi Icehong,
You may wish to post the snippets of your actual code that exhibit this
behaviour.
What you describe should not occur as packets should not be lost (unless
you set the TIPC_SRC_DROPPABLE or TIPC_DEST_DROPPABLE bits on your send
socket using setsockopt()). But it is possible you have discovered a
bug.
Questions:
1. Is it possible that your link between sender and receiver may have
gone down at any time?
2. What version of TIPC are you using?
3. What operating system and what version of that OS are you using?
Elmer
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ? ?
Sent: Thursday, March 13, 2008 10:17 AM
To: tipc-discussion@lists.sourceforge.net
Subject: [tipc-discussion] About SOCK_RDM socket
Hi ,
I write a sample test routine and want to test a SOCK_RDM socket
tipc socket,
The server routine receive packets and then drop it , then sleep
for 10 ms ,
while (1) {
recv the packet ;
usleep 1 ;
}
and the client send packets continously, I think when the receive
buffer is full, the client should be blocked. But the result is the
client continously send the packets. I found same packets were lost
after a few minutes.
from linux man page :
SOCK_RDM Provides a reliable datagram layer that does not guarantee
ordering.
Am I misunderstanding the documents or it's a bug of tipc ?
Thanks for your help,
icehong
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] About SOCK_RDM socket
SOCK_RDM (just as SOCK_STREAM) with TIPC guarantees both delivery and
ordering if you use it on a connection. And the sender will block if the
responder doesn't read fast enough.
However, if you use it connectionless the messages will be rejected when
the reception queue in the receiving socket overflows. The message may
then be dropped (if the dest_droppable bit is set), or sent back to the
sending socket with an error code. You'll then find the (first 1024
bytes of) message in the ancilliary data queue of the sender socket.
///jon
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ? ?
Sent: March 13, 2008 10:17 AM
To: tipc-discussion@lists.sourceforge.net
Subject: [tipc-discussion] About SOCK_RDM socket
Hi ,
I write a sample test routine and want to test a SOCK_RDM socket
tipc socket,
The server routine receive packets and then drop it , then sleep
for 10 ms ,
while (1) {
recv the packet ;
usleep 1 ;
}
and the client send packets continously, I think when the receive
buffer is full, the client should be blocked. But the result is the
client continously send the packets. I found same packets were lost
after a few minutes.
from linux man page :
SOCK_RDM Provides a reliable datagram layer that does not guarantee
ordering.
Am I misunderstanding the documents or it's a bug of tipc ?
Thanks for your help,
icehong
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] About SOCK_RDM socket
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 .
Is there any socket option that support reliable packet deliver
on connectioness socket ? * *
Questions:
1. Is it possible that your link between sender and receiver may have gone
down at any time?
The link is ok .
2. What version of TIPC are you using?
TIPC 1.7.5 with linux2.6.24 patch
3. What operating system and what version of that OS are you using?
linux 2.6.24 .
2008/3/13, Jon Maloy [EMAIL PROTECTED]:
SOCK_RDM (just as SOCK_STREAM) with TIPC guarantees both delivery and
ordering if you use it on a connection. And the sender will block if the
responder doesn't read fast enough.
However, if you use it connectionless the messages will be rejected when
the reception queue in the receiving socket overflows. The message may then
be dropped (if the dest_droppable bit is set), or sent back to the sending
socket with an error code. You'll then find the (first 1024 bytes of)
message in the ancilliary data queue of the sender socket.
///jon
--
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *? ?
*Sent:* March 13, 2008 10:17 AM
*To:* tipc-discussion@lists.sourceforge.net
*Subject:* [tipc-discussion] About SOCK_RDM socket
Hi ,
I write a sample test routine and want to test a SOCK_RDM socket
tipc socket,
The server routine receive packets and then drop it , then sleep for
10 ms ,
while (1) {
recv the packet ;
usleep 1 ;
}
and the client send packets continously, I think when the receive
buffer is full, the client should be blocked. But the result is the client
continously send the packets. I found same packets were lost after a few
minutes.
from linux man page :
SOCK_RDM Provides a reliable datagram layer that does not guarantee
ordering.
Am I misunderstanding the documents or it's a bug of tipc ?
Thanks for your help,
icehong
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] About SOCK_RDM socket
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/vse012070mrt/direct/01/ ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
