Freddie Chopin wrote:
I know that and in both cases the PCB stays active. But in case nr 1 it
quickly goes into TIME_WAIT state while in case nr 2 it says in
FIN_WAIT_1 forever...
Oh, I didn't see that in your last mails, sorry. That sounds odd, yes. I
haven't seen that before and I have no ex
On Thu, 2017-01-26 at 20:02 +0100, goldsi...@gmx.de wrote:
> Freddie Chopin wrote:
> > But what difference in reception does it make - in both cases
> > (with/without delay) the netconns are closed and deleted anyway.
>
> What you might be mising is that the netconn can be deleted with the
> pcb
Freddie Chopin wrote:
But what difference in reception does it make - in both cases
(with/without delay) the netconns are closed and deleted anyway.
What you might be mising is that the netconn can be deleted with the pcb
being still alive?
Simon
___
On Thu, 2017-01-26 at 15:42 +0100, goldsi...@gmx.de wrote:
> > [..] It works only if I
> > introduce a small delay between close+delete and opening of new
> > listen
> > connections (I'm using a multithreading system).[..]
> > With this code the PCBs are only sometimes stuck in TIME_WAIT state
> >
Freddie Chopin wrote:
Would any additions to the netconn API be accepted
Yes.
or maybe the plan
is really to add a function or two to sockets to allow netconn-like
interface (with no copying) and then netconn would be deprecated?
That's the longterm plan only...
[..] It works only if I
in
On Wed, 2017-01-25 at 20:49 +0100, goldsi...@gmx.de wrote:
> In "specialities" like this one, the netconn API is (unfortunately)
> sometimes incomplete as the "core" and socket APIs are more widely
> used.
>
> While you don't have to "mess" with the "so_options" field, you'd
> have
> to call "ip
Freddie Chopin wrote:
[..]
Is there any other way than direct messing
with the tcp_pcb to set SOF_REUSEADDR in the so_options field? Maybe
I'm doing something wrong here (except force-closing the client
connections (; )?
In "specialities" like this one, the netconn API is (unfortunately)
some
Hello!
Currently in a project with lwIP I'm facing an issue with closing
netconns and I failed to find a solution by myself, so I'm writing here
in hope for some guidance.
Let's say that there are 5 listening netconns, each bound to a
different port, let's say 1001-1005. I'm accepting 5 different
