Re: [Xenomai] A fix to few generic issues in rttcp stack

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On Fri, Apr 01, 2016 at 09:36:26AM +0000, Matti Suominen wrote:
> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
> Sent: 31. maaliskuuta 2016 19:23
> To: Matti Suominen <matti.suominen@wapice.com>
> Cc: Lassi Niemistö <lassi.niemisto@wapice.com>; xenomai@xenomai.org
> >> TCP is disabled in Xenomai 3 rtnet. The main problem is that creating 
> >> a socket in Xenomai 3 requires switching to secondary mode, so the 
> >> "accept" service seems hard to implement without leaving primary mode. 
> >> Given the fact that TCP can not be a deterministic protocol, I planned 
> >> to drop TCP support in the next RTnet iteration.
> >> If you require to send messages over TCP from a thread running in 
> >> primary mode, you should rather pass the message using an XDDP socket 
> >> to a thread running in secondary mode and using plain linux TCP 
> >> sockets. You will not get more determinism with TCP in RTnet.
> >
> >The question I guess, is, why do you need rttcp ? If you really need it, 
> >then we will have to find a solution for the "accept" problem.
> >Keeping a pool of sockets ready for instance.
> >
> 
> Sorry to hear that you are planning to drop support for rttcp. It's a 
> useful feature. TCP can be used by deterministic way if your connection is 
> point to point and thus retransmission is clearly a sign for error in  
> connection. Rttcp is also significantly faster than regular tcp.
> 
> For demonstration, I ran some test in a setup with rttcp client and two 
> server implementations; one rttcp and one with regular sockets. Our tests 
> are showing that average round-trip-time for same server application is 
> half when using rttcp instead of normal Linux sockets (470 µs vs. 960 µs). 
> Maximum rtt in our case is 4 ms for rt and easily over 10 ms for normal 
> Linux sockets. Each send/recv call with regular sockets drops to secondary 
> mode so there is no way the rtt maximum could be deterministic. Dropping 
> does not happen in rttcp.

Ok, I understand your point of view. I would say in that case you
could use UDP instead of TCP, but I guess you do not get to choose
the underlying IP protocol of application level protocols.

> 
> In many applications it isn't a problem when accept drops to secondary 
> mode, because creating a connection surely doesn't need to be a real time 
> operation when connection serving is still real time. Of course accept 
> which drops to secondary mode is kind a blemish when you think a big 
> picture of real time kernel, but definitely isn't a reason to drop rttcp 
> away.

>From what I understood looking at TCP servers it is very common for
a server to be implemented with one big select loop which both
accepts new connections and sends/receives to existing ones. If
accept drops to secondary mode and you want to keep communication
with existing connections in primary mode, you will have to split
the loop in two threads and have a means of communication (message
queueus for instance, or XDDP sockets) between the two threads. This
makes the job of porting a TCP server to RTnet harder than it should
be. I wonder if we can not hide that second thread in Xenomai
libraries (like is done for printf) and have listen and accept
handle the synchronization with it.

> 
> From my point of view it is clearly useful feature if same application 
> (for example Modbus/TCP) can be used from rt and pc clients, and I thus do 
> not need to maintain two protocols.

Ok, I will try to think of something.

-- 
					    Gilles.
https://click-hack.org