We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello all,
I'm using the RealView Realtime Libary V3.10 and the RTX-Kernel. I want to implement an embedded server application based on a MCB2300 Board. So I tried the tcp sockets from the Realtime Libary. I just played around to get some experience how it works.
So the server is listening and waiting for a connection. If the client is connected, the server sends a "Hallo" (hello) and is waiting for data. If the first data packet is recieved by the server, it is sending a "Tschau"(Bye) and is closing the connection with the function tcp_close().
To test the example I used a simple telnet client and connect to the embedded server. Everything is working fine, but the closing of the connection has a myserios error. To get some informaztion whats happening I used Wireshark.
I could see the following packets. (I used the FTP Port to improve the display of the send Data.)
No. Time Source Destination Protocol Info SrcPort 6 6.068468 192.168.104.120 192.168.104.220 TCP 1237 > ftp [SYN] Seq=0 Len=0 MSS=1260 1237 7 6.111373 192.168.104.220 192.168.104.120 TCP ftp > 1237 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1260 ftp 8 6.111423 192.168.104.120 192.168.104.220 TCP 1237 > ftp [ACK] Seq=1 Ack=1 Win=65535 Len=0 1237 9 6.148777 192.168.104.220 192.168.104.120 FTP Response: Hallo ftp 10 6.311293 192.168.104.120 192.168.104.220 TCP 1237 > ftp [ACK] Seq=1 Ack=8 Win=65528 Len=0 1237 11 7.972288 192.168.104.120 192.168.104.220 FTP Request: k 1237 12 8.001030 192.168.104.220 192.168.104.120 TCP ftp > 1237 [ACK] Seq=8 Ack=2 Win=5840 Len=0 ftp 13 8.012089 192.168.104.220 192.168.104.120 FTP Response: Tschau ftp 14 8.170622 192.168.104.120 192.168.104.220 TCP 1237 > ftp [ACK] Seq=2 Ack=16 Win=65520 Len=0 1237 15 8.207028 192.168.104.220 192.168.104.120 TCP ftp > 1237 [FIN, ACK] Seq=16 Ack=2 Win=5840 Len=0 ftp 16 8.207066 192.168.104.120 192.168.104.220 TCP 1237 > ftp [ACK] Seq=2 Ack=17 Win=65520 Len=0 1237 17 8.207312 192.168.104.120 192.168.104.220 TCP 1237 > ftp [FIN, ACK] Seq=2 Ack=17 Win=65520 Len=0 1237 18 8.264813 192.168.104.220 192.168.104.120 TCP ftp > 1237 [FIN, ACK] Seq=17 Ack=3 Win=5840 Len=0 ftp 19 12.224794 192.168.104.220 192.168.104.120 TCP ftp > 1237 [FIN, ACK] Seq=17 Ack=3 Win=5840 Len=0 ftp 20 12.224830 192.168.104.120 192.168.104.220 TCP 1237 > ftp [RST] Seq=3 Len=0
So it seems the Tcp-Stack ignores the ACK and the FIN, ACK send by the client as a reaction to to FIN, ACK send by the server to close the connection. Then the server sends again FIN, ACK because he thinks client didn't recieve them. Finally the client sends a RST to closed the connection that has the error.
The HTTP-Server as part a Tcp-Stack is running without this error. So I can eliminate the possibility of a missconfiguration.
Has anybody similar experiences with the closing of a tcp connection? Any ideas what could be wrong?
I would be happy to get some experience from people using the Tcp-Interface of the Realtime Libary.
Thanks Rainer
Hello Franc Urbanc
first thanks for your reply.
I implemented a wait until the socket is closed, but the socket didn't change it's state anymore until the timeout of the client socket send the reset.
But I got some new experiences... Because I didn't state much information about the implementation details in my first post, I will have to do it now..
As I already said I used the TCP-Stack together with the Realtime-Kernel. I implemented the link between the stack and the application with the help of the mailbox as suggested in the documentation. The TCP-callbackfunction simply sends a message with the event to the application-task that is waiting for a message from the mailbox. So there are at least to tasks (Tcp-task and application task). To improve the processing of the application the according task had a higher priority as the tcp-task.
So this is what happend from my point of view: So when the ACK recieved from the client the tcp-task called the callback-function and sends the appropriate. message to the mailbox of the application task. Immediately the callback-function was interuppted and a task-switch from the tcp-task to the application task happend because of the send message. The application recognized the Ack-Event and called tcp_close. The tcp-message with the set FIN flag was send successfully so tcp_close didn't return an error. But because of the interrupted tcp-callbackfunction somehow an error occured and the tcp-stack of the server ignores the FIN messages as a reply of the initial FIN send by the server.
To solve this issue I give the application-task the same priority as the tcp-task and it suddenly worked correctly. So the risky task-switch doesn't occur in the callback-function and happens at the end of the tcp-task with the os_tsk_pass() function. So it works for the first time, but I know it's not very safe yet.
To sum up, the documentation of the TCP-stack should be improved. Some more extensive examples and hints would be helpful to reduce the time of testing to get the experience needed to work with it.