Hello
I have brought in the lib xtcp 6.0.0 and modified the simple webserver demo into a TCP echo server with persistent connection until closed by peer (basically the same as TCP echo service).
I am using circuit based on MC audio board and also running the AVB/TSN stack with TDM master and RGMII, but with 100Mbps support only (GbE removed) per http://www.xcore.com/viewtopic.php?f=26&t=4731&p=24242
I am testing the echo server by opening a telnet connection from a directly connected Mac that can also receive the AVB data. The issue I am seeing is if I run the lwip stack I am not receiving XTCP_CLOSED event when the peer closes telnet, but I do receive the XTCP_CLOSED event in this circumstance if I run the uIP stack. Any idea why this might be the case?
I understand the lwIP stack is supposed to be higher performance than the uIP stack which might be important at some point in time. It's not a huge issue at present but I haven't tested the throughput of the echo server. I only need about 10kbps right now so I suspect (hope) uIP is capable of that unless someone knows why lwIP is not issuing the XTCP_CLOSED event when the peer closes the connection.
Or is there any compelling reason to use lwIP rather than uIP?
lwIP issue with remote close of persistent TCP connection Topic is solved
-
- XCore Expert
- Posts: 580
- Joined: Thu Nov 26, 2015 11:47 pm
-
- Posts: 5
- Joined: Fri Jul 28, 2017 9:55 am
Hi akp,
I have been able to reproduce your issue. It comes from our lib_xtcp wrapper around LWIP.
We are not correctly handling a LWIP_EVENT_RECV event with a NULL pbuffer.
This should be treated as a disconnect event, and forwarded to the application as a XTCP_CLOSED event.
This will be corrected in a future release.
Until this is fixed, change the code at https://github.com/xmos/lib_xtcp/blob/m ... ip.xc#L576 from
to
This should solve your problem.
Kind Regards,
Jake
I have been able to reproduce your issue. It comes from our lib_xtcp wrapper around LWIP.
We are not correctly handling a LWIP_EVENT_RECV event with a NULL pbuffer.
This should be treated as a disconnect event, and forwarded to the application as a XTCP_CLOSED event.
This will be corrected in a future release.
Until this is fixed, change the code at https://github.com/xmos/lib_xtcp/blob/m ... ip.xc#L576 from
Code: Select all
case LWIP_EVENT_RECV:
if(p != NULL) {
enqueue_event_and_notify(pcb->xtcp_conn.client_num, XTCP_RECV_DATA, &(pcb->xtcp_conn), p);
}
break;
Code: Select all
case LWIP_EVENT_RECV:
if(p != NULL) {
enqueue_event_and_notify(pcb->xtcp_conn.client_num, XTCP_RECV_DATA, &(pcb->xtcp_conn), p);
} else {
enqueue_event_and_notify(pcb->xtcp_conn.client_num, XTCP_CLOSED, &(pcb->xtcp_conn), NULL);
}
break;
Kind Regards,
Jake
-
- XCore Expert
- Posts: 580
- Joined: Thu Nov 26, 2015 11:47 pm
Hi Jake,
Thanks, I will try that out.
By the way, I have updated xtcp_uip and xtcp_lwip to be combinable. Tested ok with xtcp_uip and will be testing with xtcp_lwip... any reason I wouldn't want to run the ip task combinable? Seems an obvious thing to do cooperative multitasking with, especially if you have another IP task like the echo server I mentioned.
Thanks, I will try that out.
By the way, I have updated xtcp_uip and xtcp_lwip to be combinable. Tested ok with xtcp_uip and will be testing with xtcp_lwip... any reason I wouldn't want to run the ip task combinable? Seems an obvious thing to do cooperative multitasking with, especially if you have another IP task like the echo server I mentioned.
-
- XCore Expert
- Posts: 580
- Joined: Thu Nov 26, 2015 11:47 pm
Hi Jake,
Thank you, that solved the problem. My updates to xtcp_uip and xtcp_lwip to make the combinable seem to work in case xmos is interested in the change. Pretty straightforward, just made new unsafe {} sections inside the while (1) { select { statements (rather than putting the whole while (1) { select { in an unsafe {} section) so it would meet the combinable criterion.
Best,
Adam
Thank you, that solved the problem. My updates to xtcp_uip and xtcp_lwip to make the combinable seem to work in case xmos is interested in the change. Pretty straightforward, just made new unsafe {} sections inside the while (1) { select { statements (rather than putting the whole while (1) { select { in an unsafe {} section) so it would meet the combinable criterion.
Best,
Adam