From c5a9c367517176c9a1173fb12050c9fc2f553787 Mon Sep 17 00:00:00 2001
From: patacongo <patacongo@42af7a65-404d-4744-a932-0658087f49c3>
Date: Thu, 20 Nov 2008 21:59:36 +0000
Subject: [PATCH] update
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@1296 42af7a65-404d-4744-a932-0658087f49c3
---
TODO | 19 +++++++------------
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/TODO b/TODO
index 9ea6c61b7a..3c6caa36d1 100644
--- a/TODO
+++ b/TODO
@@ -1,4 +1,4 @@
-NuttX TODO List (Last updated November 19, 2008)
+NuttX TODO List (Last updated November 20, 2008)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(7) Task/Scheduler (sched/)
@@ -7,7 +7,7 @@ NuttX TODO List (Last updated November 19, 2008)
(1) Signals (sched/, arch/)
(1) pthreads (sched/)
(1) C++ Support
- (15) Network (net/, netutils/)
+ (12) Network (net/, netutils/)
(1) USB (drivers/usbdev)
(4) Libraries (lib/)
(6) File system/Generic drivers (fs/, drivers/)
@@ -190,22 +190,17 @@ o Network (net/, netutils/)
Priority: Low
Description: At present, there cannot be two concurrent active TCP send
- operations in progress. This is because the uIP ACK logic will
- support only one transfer at a time. The solution is simple:
- A mutex will be needed to make sure that each send that is
- started is able to be the exclusive sender until all of the
- data to be sent has been ACKed.
+ operations in progress using the same socket. This is because
+ the uIP ACK logic will support only one transfer at a time. The
+ solution is simple: A mutex will be needed to make sure that each
+ send that is started is able to be the exclusive sender until all of
+ the data to be sent has been ACKed.
Status: Open. There is some temporary logic to examples/nsh that does
this same fix and that temporary logic should be removed when
send() is fixed.
Priority: Medium-Low. This is an important issue for applications that
send on the same TCP socket from multiple threads.
- Description: Some application-level interface to the ICMP logic is needed
- to support ping from the target.
- Status: Open
- Priority: Low
-
Description: TCP supports read-ahead buffering to handle the receipt of
TCP/IP packets when there is no read() in place. Should such
capability be useful for UDP? PRO: Would reduce packet loss
--
GitLab