[Top][All Lists]

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

[lwip-devel] [patch #6537] wnd_scale TCP option addition

From: Rishi Khan
Subject: [lwip-devel] [patch #6537] wnd_scale TCP option addition
Date: Fri, 20 Jun 2008 15:26:51 +0000
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv: Gecko/20080404 Firefox/

Follow-up Comment #2, patch #6537 (project lwip):

Answers to questions:
1) why are the various window sizes in tcp.h changed to u32_t - I thought
they were still limited to 65536?
rcv_ann_wnd, and snd_wnd are u32_t because of:
tcphdr->wnd = htons(pcb->rcv_ann_wnd >> pcb->rcv_scale);
pcb->snd_wnd = tcphdr->wnd << pcb->snd_scale

I think you are right about rcv_wnd.

2) why is snd_queuelen increased to u32_t - I can't foresee having more than
65536 segs for a single PCB!

In lwipopts I see this:
/* TCP sender buffer space (pbufs). This must be at least = 2 *
   TCP_SND_BUF/TCP_MSS for things to work. */

Therefore, if the snd_buf needs to be tcphdr->wnd << pcb->snd_scale, so if
the snd_scale is greater than log2(TCP_MSS), then there is a problem. I've
never seen a snd_scale greater than 7, so this is highly unlikely and
snd_queuelen is probably fine as u16_t.

I agree with your readability changes for optdata. 

However, I don't think the RCV_WND_SCALE #define will work because you need
to do the htons AFTER the shift, not before. So, for this one, how about:
#define RCV_WND_SCALE(pcb, wnd) (htons((wnd) >> (pcb)->rcv_scale))
and seg->tcphdr->wnd = RCV_WND_SCALE(pcb, pcb->rcv_ann_wnd); 

So, if we agree that we need to keep rcv_ann_wnd and snd_wnd as u32_t, and
change RCV_WND_SCALE I will make the other changes and a new patch.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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