mguentner
CAN frame spanning two TCP packets + default WINDOW SIZE
Hello, I have turned to using cannelloni over TCP instead of UDP due to the issues I mentioned in #72 which are hard to reliably resolve. I have come across the following observation, and I wanted to get your input on them just to better understand how things work behind the scenes.
First of all, I notice that cannelloni advertises a small window of 1152 bytes and I wonder if it's due to cannelloni's internal config or it's related once again to my Linux kernel configuration.
Furthermore, I have observed that if I return CAN frames from my remote node that get split across TCP packets (i.e a frame starts at the end of the packet and finishes at the beginning of the next one), cannelloni seems to return a CAN frame with empty data.
I admit I have not properly investigated yet the behavior, and it was a quick observation after a test I was running, where my application code would read a CAN frame but without data in it (using python-can). Is it something that you have seen before or any general insights into it?
For my setup I refer to #72 once again.
Thanks for you time.
Saverio.
I have never observed that. The TCP/IP stack should abstract all this for you, cannelloni only reads from a stream socket. How is it implemented on the STM32 side? Can you replicate the behavior with two Linux boxes?
