Bug 141 – udp tx buffer is not fixed size

Bug 141 - udp tx buffer is not fixed size

Summary:

udp tx buffer is not fixed size

Status:	NEW

Product:	ns-3
Component:	internet-stack
Version:	pre-release
Platform:	All All

Importance:	P3 normal
Assigned To:	ns-bugs

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2008-02-15 12:32 EDT by Mathieu Lacage
Modified:	2009-11-24 00:05 EDT (History)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description From Mathieu Lacage 2008-02-15 12:32:21 EDT

We need to make it a fixed size and handle correctly sending udp packets which
do not fit in the tx buffer.

First, we need to figure out what we should do in the latter case and what
happens in linux udp sockets when the tx buffer is full: are packets dropped ?

------- Comment #1 From Gustavo J. A. M. Carneiro 2008-02-16 09:31:17 EDT -------

I don't think UDP sockets have transmit buffer in Linux. See
http://book.chinaunix.net/special/ebook/oreilly/Understanding_Linux_Network_Internals/0596002556/understandlni-CHP-21-SECT-1.html#IDX-CHP-21-2574

    """udp_sendmsg first calls ip_append_data, and then forces the immediate
transmission of the data with udp_push_pending_frames only if corkreq is
false"""

But the "cork" option is an advanced udp socket option, disabled by default. 
By default UDP has no buffering; there's only a transmit queue in the netdevice
itself.

------- Comment #2 From Mathieu Lacage 2008-06-06 14:54:53 EDT -------

until we implement CORKED udp sockets or the MSG_MORE socket flag for udp
socket options, we do not need to worry about this issue I think. I would like
to decrease the priority of this bug.

------- Comment #3 From Tom Henderson 2008-06-06 17:51:09 EDT -------

OK, bumping to p3

------- Comment #4 From Mathieu Lacage 2009-11-23 08:40:44 EDT -------

Maybe we should just mark this bug as WONTFIX. tom ?

------- Comment #5 From Tom Henderson 2009-11-24 00:05:24 EDT -------

(In reply to comment #4)
> Maybe we should just mark this bug as WONTFIX. tom ?

I have no plans to work on this enhancement.  WONTFIX ok for me.