Re: [lwip-users] Using pbufs in a recv function - next vs ref vs tot_len

[Paul C]

Hi Chris,

Here is a skeleton of the code I use.

static err_t
recv(void *arg, struct tcp_pcb *pcb, struct pbuf *p, err_t err)
{
    struct pbuf *q;
    
    if (p == NULL)
    {
        // called with pbuf == NULL means other end has closed 
        // close_conn should destroy arg and do tcp_close(..)       
        return close_conn(pcb, arg);
    }

    q = p;
    while (q)
    {
      u16_t length = q->len;
      u8_t *cmdPtr = (u8_t*)q->payload;

      while (length)
      {
            {
            // process the input one char at a time
            // use arg for tracking the state of the input 
            }
                length--;
                cmdPtr++;
      }
      q = q->next;
    }                   
    tcp_recved(pcb, p->tot_len );               
    (void) pbuf_free(p);
    return ERR_OK;
}

On Tue, 11 Jan 2005 18:55:51 -0800, "Chris Frost" <address@hidden>
said:
> I've been tracking down a bug in a program using lwip's rawapi, but my
> solution seems odd so I was hoping to ask a quick question about the use
> of pbuf's in one's recv function (that is passed to tcp_recv).
> 
> Originally, I did something like this:
> recv(void *arg, struct tcp *pcb, struct pbuf *p, err_t err)
> {
>       for(; p; p = p->next)
>       ...
> }
> 
> However, this seemed to be incorrect because of many asserts lwip made,
> eg
> pbuf_free: p->ref > 0. From the code in lwip that I found, all pbuf code
> appeared to do this, but perhaps I've misread code, or the pbuf structure
> is used differently in different places? My first change was to add to
> the for
> condition p->ref > 0. I then found I would receive much more data than
> was going across the network. (In particular, large regions of zeros.)
> In addition to next and ref there is the tot_len field. Changing the for
> loop condition to (p && bytes_recved < total_bytes_from_orig_p_tot_len)
> appears to work perfectly. So this is good. :)
> 
> My question is, is this use of pbufs in the recv function correct? While
> it functional appears to be, it seems odd to me (not being too familiar
> with lwip's internal workings) that length, ref, and next do not agree on
> when the data in a list of pbufs ends. The lwip code I have looked at
> that
> uses pbufs (and our ethernet driver) just checks what seems most obvious,
> next. I've not read any applications that use pbuf lists, the only one
> I have seen is the http client in contrib, but this only inspects the
> first pbuf.
> 
> thanks for any help clearing up/confirming the use of the pbuf interface!