[Xenomai] A fix to few generic issues in rttcp stack
gilles.chanteperdrix at xenomai.org
Sun Apr 3 21:09:48 CEST 2016
On Thu, Mar 31, 2016 at 10:33:09AM +0000, Matti Suominen wrote:
> I have case where we use rtnet's tcp socket in server application to
> communicate with real time and non-real time tcp clients. To get
> communication work between client and server I had to do some changes to
> stack/ipv4/tcp/tcp.c file.
> First. Original tcp flag enumeration didn't work at all in this case. This
> was verified by using Wireshark to track communication which didn't show
> me any flags in tcp packets. This was solved by replacing flags assigning
> TCP_FLAG_ prefixed enums with TCPHDR_ prefixed defines from <net/tcp.h> in
> stack/ipv4/tcp/tcp.c file. The original code only works in case of little
> endian machine, as rt_tcp_set_flags function places assumption that flags
> are located in the least-significant 8bits of the 32bit flag variable.
> This approach is similar to what regular TCP is using:
> Second. Server was able to receive messages from client but was unable to
> reply messages. I was able to trace function calls by adding debug prints
> to tcp.c functions and noticed that accepted socket wasn't signaled for
> "ready to send" at all and server was unable to reply messages. This seems
> to work properly if the send signal is posted in the end of the accept
> function, which also would seem the logical way to initialize it once
> connection has been established.
> Third. In our case we have regular Linux tcp sockets and rtnet tcp sockets
> working parallel, serving different services. Referred to this I noticed
> that *rt_tcp_dest_socket() may cause problem when real time stack
> processes a message targeted to a regular Linux socket and does not find a
> rttcp socket for it. The rttcp stack then tries to send RST|ACK to client
> to terminate the connection. This is temporarily disabled by setting
> "if (!th->rst)" clause into #ifdef YET_UNUSED. This should be corrected
> for example by implementing layer which is able to loop also non real time
> sockets. Or is it really a desired rttcp design principle to unsupport the
> usage of regular Linux tcp sockets in parallel?
I am going to merge your patch for the time being. However, I have a
question about using rttcp in parallel with Linux tcp: are you using
the rtnetproxy module? If yes, then testing for
CONFIG_XENO_DRIVERS_NET_ADDON_PROXY and the rt_ip_fallback_handler
pointer would be the way to go.
More information about the Xenomai