@cgundogan, maybe you are interested, too.

Please don't use sub-directories in tests (except unittests). See e.g. thread and vtimer tests.

@brummer-simon, what's the latest on this one?

Currently I am running in a bunch of problems with implementing TCP. I suspect the cause of it in RIOTs scheduling model and timer implementation. The non-premetive scheduling model seems to be the biggest obstacle because RFC 793 assumes a premetive scheduler.

Currently I'll write it down and upload the pdf up for discussion.

The non-premetive scheduling model seems to be the biggest obstacle because RFC 793 assumes a premetive scheduler.

Huh? Since when does RIOT has a non-preemptive scheduler? Don't confuse the fact that RIOT's scheduler works without timeslices to interrupt threads periodically with the fact threads are preemptible.

Okay. Still the Problem is, main Function runs as long as it doesn't put itself to sleep or wait for a message or what ever. After that TCP is able to do actual work. And this is a Problem. The TCP-Thread must be able react on incomming data as soon as possible, independently from userspace.

As far as is see it this is currently a huge obstacle and i am not sure how to solve it.

Okay as general scheduling questing. If my TCP-Thread has a higher priority than my main-Thread and the TCP-Thread is currently waiting for a message, the main thread is running.

If a message for the tcp thread commes in, will there be a context switch to the tcp thread as soon as the message comes in or after the main thread puts it self to sleep ?

If a message for the tcp thread commes in, will there be a context switch to the tcp thread as soon as the message comes in or after the main thread puts it self to sleep ?

As soon as the message comes in.

Ah okay. Then I see why its not a non-premptive scheduler. Still i'll have to figure out where exactly my Problem is.

Let us know as soon as you've figured out what the problem is. Maybe we can help.

Native and the samr-xpro board.

Yes and Yes. Currently I focus more on Bugfixing on native.

Also note that in order to give a thread a higher priority means that you
assign it a lower number for the priority value IIRC.
On Aug 11, 2015 11:57 AM, "Kaspar Schleiser" notifications@github.com
wrote:

Okay. Still the Problem is, main Function runs as long as it doesn't put
itself to sleep or wait for a message or what ever. After that TCP is able
to do actual work. And this is a Problem. The TCP-Thread must be able react
on incomming data as soon as possible, independently from userspace.

Give TCP a higher priority (lower priority value) than main, if your
main does busy-waiting.

—
Reply to this email directly or view it on GitHub
#2827 (comment).

Okay followup question about scheduling.

My main thread is waiting for a message. the tcp thread is running and it is sending a message to the main thread.

The priority of the tcp thread is higher than main(a lower number). After the message was sent from tcp to main, main takes over. That means the priority is raised after getting a message from a higher prioritzed thread. Is that right?

Ist there somehow a tutorial how the scheduler behaves?

The priority of the tcp thread is higher than main(a lower number). After the message was sent from tcp to main, main takes over. That means the priority is raised after getting a message from a higher prioritzed thread. Is that right?

Not quite. After TCP thread sent the message to main thread, TCP will keep running. Just the main thread will change its state to PENDING, i.e. it will continue to run as soon as no thread with a higher priority is in the run queue.

Ist there somehow a tutorial how the scheduler behaves?

I'm not sure. At least there should be something in @kaspar030's thesis IIRC.

The segfault has to do with the the nomac driver releases the packet back to the packet buffer if it has send it. Then new data is wrote over the previous gnrc_pktsnip_t however the TCP tcb uses that the now overwritten pointers cur_pkt and cur_tcp_hdr to try and resend the data.

The SYN/ACK still is invalid though, the TCP header is correct but although gncr_ipv6.c sets the src address. When the packet is send however the src address, next header and payload are invalid / not set.

Any ideas?

Related to issue: #3707

When we want to keep the packet for the retry timer etc. however when used is set to 1 the response would be valid but the packet is overwritten by another packet and when TCP tries to resend it, it would resend an overwritten packet.

However when you set the used count to 2 since you want to keep a copy of the packet in the retry queue an invalid IPv6 header would be send.

Okay I pulled the current Master and DipSwitchs Branch that did the whole renaming(Thanks by the Way:) ) and squashed the hole thing.

I'll try to get the handshake going

The handshake is working :) I think we can start sending data :D

Nice. 😎

My original goal was to implement the connection termination first, to make sure the fsm work as it should be. But as i wrote yesterday, I focus the next months on my Bachelor Thesis.

Oh the merge included a lot files that aren't involved in the hole tcp thing. I'll fix that in the afternoon.

Both are even important :) good luck with your thesis!

@DipSwitch please comment in the PR not the commit. Comments in commits get easily lost.

You probably need to rebase to current master. There are a lot of changes in here now, that are actually a part of master already.

I rebased and forced updated, sorry not the best way possible...

If you do close implementation, I'll see if I can start with send in my free time ^_^

Yes I'll implement the close operation. Over the next weeks.

The last time I tried (about 1 month ago), I was not able to get the test application to send anything (not even the handshake packets).
As far as I can see, what would be the "eventloop" (as it is called in other gnrc modules) corresponds to the _fsm function here. However, this seems not to implement a common event loop for all TCP connections, but just for one connection. This would require every TCP connection to run its own thread which is most likely a bad idea. I would advice to use a central eventloop (just similar to what other gnrc modules do) and make all calls to TCP based on gnrc netapi calls.

Some more "formal" comments:

• Defining such a long function as the current _fsm() static inside a header is IMO not a good style. Please move this to a C file.
• The code could need some uncrustifying

Hi Oleg,

currently i'am doing buzy spliting the static includes into thier own c-Files, and doing some renaming. For your concern with the _fsm corresponance.

TCPs statemaschine must be able to do translations, without the users interaction, in case a FIN-Packet was received. Moving from ESTABLISHED to CLOSE_WAIT. The Eventloop interacts only in case of Packet reception with the FSM. The Transmission control blocks are organized as a linked list. If the eventloop receives a packet, it looks for the receivers pid. The pid is part of an tcb as well. The eventloop searches for the receivers tcb and calls the fsm-function with this specific tcb.

Long story short, only one eventloop is needed for multiple connections.

Merge fuckup lead to this pull request: #4744

closed in favor of #4744