Re: [lwip-users] Questions about how to get a robust lwIP TCP Raw API server application.

[Dinesh Pandey]

There is an OS, but LWIP (and the associated application) runs as an independent task (NO_SYS=1).

Cheers

DP.

On Wed, Nov 4, 2015 at 5:47 PM, Noam Weissman <address@hidden> wrote:

Hi,

 

Do you use an OS or is this all of your code ?

 

Noam.

 

 

From: lwip-users-bounces+noam=address@hidden [mailto:lwip-users-bounces+noam=address@hidden] On Behalf Of Dinesh Pandey
Sent: Wednesday, November 04, 2015 10:31 AM

To: Mailing list for lwIP users
Subject: Re: [lwip-users] Questions about how to get a robust lwIP TCP Raw API server application.

 

Hi Naom,

I guess we are trying to say the same thing. Just to be clear, this is how I write the main loop:

while(1)
{

    ethernetif_input();

    sys_check_timeouts();

    my_own_poll();

}

my_own_poll() checks for external inputs and internal states and calls tcp_write if needed. The receive callback simply updates the state (or stores data) for my_own_poll to check and do its job.

Cheers

DP

 

On Wed, Nov 4, 2015 at 12:40 PM, Noam Weissman <address@hidden> wrote:

Hi DP,

 

If you mean calling a function and handling data out of the callback itself but from the same context

It is OK

 

I mean for example:

 

err_t  foo(void *arg, struct tcp_pcb *pcb)

{

  Return  tcp_write(pcb, &Data[DataSent], SendData, TCP_WRITE_FLAG_COPY);

}

 

err_t tcp_recv(void *arg, struct tcp_pcb *pcb, struct pbuf *pBuf, err_t err)

{

  Some code

.

.

.

   Then call :

   foo(arg, pcb);

}

 

 

In the above pseudo code you handle a tcp_write but it is in the same context of the callback.

This is OK.

 

The problem arises if you call tcp_write from a different task !! If that happens it seems to work

but if you transfer lots of data you will start seeing strange behavior. I have noticed out of memory

problems (TCP stack memory).

 

The reason is that LwIP has its own internal housekeeping and if you call LwIP functions outside of

the TCP stack context this housekeeping will fail as it is not synchronized with the code from a

different task.

 

Hope that helped.

 

BR,

Noam.

 

From: lwip-users-bounces+noam=address@hidden [mailto:lwip-users-bounces+noam=address@hidden] On Behalf Of Dinesh Pandey
Sent: Wednesday, November 04, 2015 8:29 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Questions about how to get a robust lwIP TCP Raw API server application.

 

"Ok for the write outside of the receive callback. But is it safe and robust?"

Never thought about it. I have always called tcp_write outside of the receive callback. I can't see any problem as long as everything is done in the same thread. tcp_write only queues up the data for writing. tcp_output flushes out the data. I doubt calling it inside the receive callback is any different from calling it outside.

"The TCP PCB still exists but with
no more active connections when we call tcp_close. And it still can accept
new incoming connections requests *UNLESS* we call tcp_accept(PCB, NULL) to
de-allocate the accept_callback (called for incoming requests) notified
after tcp_listen when starting the server."

Not sure what you are trying to do here. If you want to stop accepting new connections, do a tcp_close on the listener (the PCB on which you did bind and listen).

 

Cheers

DP

 

On Tue, Nov 3, 2015 at 11:23 PM, bom <address@hidden> wrote:

Hi and thank you for your fast answer!

"When you want to write to the TCP connection outside of the receive
callback. And yes, you can write to the TCP connection anytime (not just in
the receive callback)."

Ok for the write outside of the receive callback. But is it safe and robust?
Wouldn't it be safer if, for example, if I pass that call
tcp_write(local_PCB) only in the tcp_poll_callback() which gives me that PCB
as an argument instead of calling tcp_writing(global_PCB)?

"IIRC, there is a SO_REUSEPORT equivalent flag for LWIP. Don't remember the
exact name."

If found that in the opt.h header file :

opt.h wrote
> /**
>  * SO_REUSE==1: Enable SO_REUSEADDR option.
>  */
> #ifndef SO_REUSE
> #define SO_REUSE                        0
> #endif
>
> /**
>  * SO_REUSE_RXTOALL==1: Pass a copy of incoming broadcast/multicast
> packets
>  * to all local matches if SO_REUSEADDR is turned on.
>  * WARNING: Adds a memcpy for every packet if passing to more than one
> pcb!
>  */
> #ifndef SO_REUSE_RXTOALL
> #define SO_REUSE_RXTOALL                0
> #endif

But if found no documentation on that "SO_REUSEADDR" option in the lwIP wiki
( here <http://lwip.wikia.com/wiki/Raw/TCP>  )! Where else could I found the
meaning of that option?

------ Some investigations passed before that next part is written ------
Well, I think I just found out why my connections re-bind didn't work.
That's because I never really close it! I just close the "active connection"
on that PCB (?) !
I hope being clear enough : Once we call the "tcp_new - bind - listen -
accept" functions one after another, the TCP PCB structure is "actively
listening" to new incoming connections. And *if we call tcp_close on that
PCB, /we just close all the active connections/, but some new incoming
connections are still accepted on condition that we don't call
tcp_accept(PCB, NULL) after that* to de-assert the accept_callback function.

In short and if I understand correctly : The TCP PCB still exists but with
no more active connections when we call tcp_close. And it still can accept
new incoming connections requests *UNLESS* we call tcp_accept(PCB, NULL) to
de-allocate the accept_callback (called for incoming requests) notified
after tcp_listen when starting the server.

Am I right!? =)
Then what is the state of the TCP PCB after we call tcp_close and the
CLOSE_WAIT state is gone? Is it going back to the "LISTEN" state it was
before accepting the first connection?

Oh and while I'm here : is there a way to "undo" what the tcp_listen,
tcp_bind or tcp_new functions does?
Actually I'd guess it is (but I'm not sure) :
For tcp_new(PCB) -> tcp_abort(PCB)?
For tcp_bind(PCB, IP_ADDR_ANY, serverPort) -> tcp_bind(PCB, IPADDR_NONE, 0)
could work?
For tcp_listen(PCB) -> "Hard write" the state with a PCB->state = CLOSED
allocation? Seems weird since that would better be the result of a
tcp_close(PCB) call no?

Again sorry for that long message and thank you for your help!
Best regards.



--
View this message in context: http://lwip.100.n7.nabble.com/Questions-about-how-to-get-a-robust-lwIP-TCP-Raw-API-server-application-tp25308p25310.html

Sent from the lwip-users mailing list archive at Nabble.com.

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

 

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

 

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users