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
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 tha
Forgot to add that we can get the link up by either downgrading the
linux TIPC version or upgrading the vxWorks version. We'd like to
understand the 1.7 - 1.3 issue though as it will affect our upgrade
scenarios.
Brad
Brad Stephens wrote:
I could
use some input on what is stopping our linux
I could use some input on what is stopping our linux box, TIPC 1.7.5,
from talking to our vxWorks 6.2 box, TIPC 1.3.x. I've captured an
ethernet trace of the problem, attached. The linux box (tipc 1.1.1)
cannot establish the link with the vxWorks board (which has two
processors, TIPC addresse
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 ove
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 hav
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
