1 Jun 2012 01:34
Re: A query on SCTP client’s (running under RHEL4) performance in terms of aggregate throughput rate
Randy Stewart <randall <at> lakerest.net>
2012-05-31 23:34:40 GMT
2012-05-31 23:34:40 GMT
Chinmaya: If you are using a connected socket aka one-2-one model, then you can also use send() and that should work. The sctp_sendmsg() is also used by the one-2-many model socket, and there you need a socket address. Some implementations allow you to place a NULL in the socket address of a connected socket for sctp_sendmsg(), not sure if linux does. But this is all implementation specific stuff. R On May 31, 2012, at 8:29 AM, Chinmaya Dwibedy wrote: > > > Hi. > > We have SCTP client program (C++) running under RHEL4 (using kernel version: 2.6.9-55ELsmp and lksctp-tools-1.0.8-1). We are using one-to-one socket (also called TCP-style sockets) using connect () system call to setup an association with a server. Then it calls sctp_sendmsg () library function to send a message from a socket while using the following advanced features of SCTP i.e., SCTP_UNORDERED for un-ordered delivery of the message. The sctp_sendmsg () API takes a pointer to "sockaddr" as a parameter indicating the address of the destination. Since our client application knows well that, it will be sending the multiple messages to the same configured destination address, it would become more efficient if we will connect the socket explicitly. In summary, we can say that a SCTP client can call connect only if that process uses the SCTP socket to communicate with exactly one peer. I mean, calling connect () on the SCTP socket once simply records the specified IP address and port number as being the desired communications partner and send/write call. Anything written to a connected SCTP socket is automatically sent to the protocol address (e.g., IP address and port) specified by connect. > After connect() system call, there will be absolutely no need of again passing socket address structure(Continue reading)
In fact in general, if I remember correctly you SHOULD respond whenever possible with
the source address that sent you the packet. There are times when thats not possible
(A sack for example acking a packet that came in from two different source addresses, or
a situation where you suspect the reverse path is broke), but in general that SHOULD
also applies here as well.
R
>
> Best regards
> Michael
>> Even if there are two paths, SCTP does not have any way to determine whether two paths share links and
routers when traversing the network. The paths used by the IP packets across the network might be
different depending on the destination IP address. If a message fails to reach its destination, SCTP may
retransmit the message using a different destination IP address. If somewhere along the path a link
or/and router fails then SCTP can detect the failure of the path via a heartbeat message. These actions
done by SCTP are independent of the actions performed by the lower layers for failure detection and
restoration. Under the assumption that every IP address will have a different, separate path towards the
remote endpoint, (this is the responsibility of the routing protocols or of manual static
configuration), if the transport to one of the IP addresses (= 1 particular path) fails then the traffic
can migrate to the other remaining IP address (= other paths) within the SCTP association.
>>
>> Regards,
>> ChinmayaD
>
>
-----
Randall Stewart
randall <at> lakerest.net
RSS Feed