[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-devel] MSG_MORE flag for send
From: |
Jonathan Larmour |
Subject: |
Re: [lwip-devel] MSG_MORE flag for send |
Date: |
Sat, 27 Oct 2007 15:45:18 +0100 |
User-agent: |
Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) |
Simon Goldschmidt wrote:
Interesting patch (this functionality is required by the TCP RFCs by
the way),
Are you sure about that? We already only set PSH on the last segment of
enqueued data from a single 'write', so isn't that all that is required?
It seems more to me that this is an extension to give the user more
control over when to send a PSH, rather than it being at the end of every
'write'.
but I'd rather solve this without adding an extra parameter
to a load of functions throughout the whole stack (I can already hear
people saying' why add an extra parameter (which might be put on the
stack when calling the funciton) for something I don't need?').
I can see you glancing at me ;-). But yes, I think this patch would need
more discussion and development. I am a bit concerned with the
consequences of running out of memory (segs, pbufs, netbufs, ...) - much
more likely for us than other stacks of course. My concern, which may be
unjustified, is that PSH can affect the remote end's behaviour for ACKs.
And if so, could result in unnecessary delays before remote ACKs are
transmitted, leading to a stalled local unacked queue. I'd have to look
more closely at the RFCs and existing practice to find out for sure
admittedly.
Certainly, adding an extra param is not a requirement; this could be done
with a separate API message to set a flag in the pcb, e.g. in tcp.h:
#define TF_DELAY_PSH (u8_t)0x80U
And then in tcp_enqueue:
if (seg != NULL && seglen > 0 && seg->tcphdr != NULL &&
0 == (pcb->flags & TF_DELAY_PSH) ) {
TCPH_SET_FLAG(seg->tcphdr, TCP_PSH);
}
New equivalent functions can be provided in the higher APIs. The advantage
there being that they are left out if unused (if using a linker with dead
function garbage collection).
Rather than there being a specific API message to set this flag (which
would take space that couldn't be removed without an lwipopts.h define),
it may be better to have one to get/set any PCB flag, which has more
generic purpose.
Jifl
--
eCosCentric Limited http://www.eCosCentric.com/ The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------ Opinions==mine
- [lwip-devel] MSG_MORE flag for send, Marc CHALAND, 2007/10/26
- Re: [lwip-devel] MSG_MORE flag for send, Simon Goldschmidt, 2007/10/27
- Re: [lwip-devel] MSG_MORE flag for send,
Jonathan Larmour <=
- Re: [lwip-devel] MSG_MORE flag for send, Simon Goldschmidt, 2007/10/27
- Re: [lwip-devel] MSG_MORE flag for send, Jonathan Larmour, 2007/10/27
- Re: [lwip-devel] MSG_MORE flag for send, Frédéric BERNON, 2007/10/28
- Re: [lwip-devel] MSG_MORE flag for send, Marc CHALAND, 2007/10/29
- Re: [lwip-devel] MSG_MORE flag for send, Marc CHALAND, 2007/10/29
- RFC references (was Re: [lwip-devel] MSG_MORE flag for send), Jonathan Larmour, 2007/10/29
Re: [lwip-devel] MSG_MORE flag for send, Marc CHALAND, 2007/10/29
Re: [lwip-devel] MSG_MORE flag for send, Marc CHALAND, 2007/10/29