[Top][All Lists]
[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
- [lwip-users] tcp_poll(), event handlers and possible misinformation, Lou Cypher, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, Kieran Mansley, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, Lou Cypher, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, Jeff Barber, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, Lou Cypher, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, address@hidden, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation,
Lou Cypher <=
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, address@hidden, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, Lou Cypher, 2009/07/02
- RE: [lwip-users] tcp_poll(), event handlers and possible misinformation, Bill Auerbach, 2009/07/01
RE: [lwip-users] tcp_poll(), event handlers and possible misinformation, Bill Auerbach, 2009/07/01