lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] tcp_poll(), event handlers and possible misinformation


From: Lou Cypher
Subject: Re: [lwip-users] tcp_poll(), event handlers and possible misinformation
Date: Wed, 01 Jul 2009 19:18:11 +0200
User-agent: Thunderbird 2.0.0.22 (Windows/20090605)

> The poll handler is called for a PCB, not for specific packets, so it's
> not really clear what you mean.

A source code is worth a thousand words... My recv looks like this:
-----------------------------------------------------------
err_t   http_recv( void *arg, struct tcp_pcb *pcb, struct pbuf *p, err_t err )
{
    ...
    if ( err == ERR_OK  &&  p != NULL )
    {
        PRINTDEBUG( "recv: remote %d, size %d\r\n",
                    pcb->remote_port, p->len );

        tcp_recved( pcb, p->tot_len );
        ...
    }
    ...
}
-----------------------------------------------------------
The poll handler shows another message, with count of bytes to transmit, file
pointer, retry count, etc.
Suppose to transmit exactly 3 packets, 1460 bytes each (as per MSS).

I would expect to see on debug port something like:
-----------------------------------------------------------
recv: remote 4845, size 1460
recv: remote 4845, size 1460
recv: remote 4845, size 1460
-----------------------------------------------------------

While I obtain:
-----------------------------------------------------------
recv: remote 4845, size 1460
httpd: POLL, left: 0, file: 0, data: 0, retr.: 1
             loc.: 80, rem.: 4845, state: 4
recv: remote 4845, size 1460
-----------------------------------------------------------

The packets received are only two, the first and the last.
Every time I see (with WireShark) a packet exiting from PC client, and it gets
lost on its way to lwIP, I get a call to the poll handler (and it continues for
a number of retries, that were intended for sending).

Note: this is an example with a small file, with larger files I loose so many
packets that's hard to follow, so for now I'm debugging this way.

> Did you handle pbuf queues correctly? Did you maybe (or accidentally)
> reset the recv callback pointer in the PCB somehow? *Every second
> packet* is a bit too regularly...

The recv callback is set up on connection accept, and is never changed elsewhere
(the code comes form httpd in contrib)

>> Looks like I'm the only one in this ML sending more than 1460 bytes
>> *to* lwIP...
>>   
> 
> It's not really even worth answering this rhetorical question, but you
> definitively aren't!

Maybe I wasn't serious asking ;^)
Then I'm definitively making a mistake in data handling and I have no clue,
great! :)

Lou




reply via email to

[Prev in Thread] Current Thread [Next in Thread]