patch-2.1.15 linux/net/802/TODO

• Lines: 30
• Date: Thu Dec 12 16:54:22 1996
• Orig file: v2.1.14/linux/net/802/TODO
• Orig date: Thu Jan 1 02:00:00 1970

diff -u --recursive --new-file v2.1.14/linux/net/802/TODO linux/net/802/TODO
@@ -0,0 +1,29 @@
+Remaining Problems:
+
+1. Serialization of access to variables in the llc structure
+by mac_data_indicate(), timer expired functions, and data_request() .
+There is not serialization of any kind right now.
+While testing, I have not seen any problems that stem from this lack of
+serialization, but it wories me...
+
+2. The code is currently able to handle one connection only,
+there is more work in register_cl2llc_client() to make a chain
+of llc structures and in mac_data_indicate() to find back
+the llc structure addressed by an incomming frame.
+According to IEEE, connections are identified by (remote mac + local mac
++ dsap + ssap). dsap and ssap do not seem important: existing applications
+always use the same dsap/ssap. Its probably sufficient to index on 
+the remote mac only. 
+ 
+3. There is no test to see if the transmit window is full in data_request()
+as described in the doc p73, "7.5.1 Sending I PDUs" 3th alinea.
+The pdus presented to data_request() could probably go on the 
+awaiting-transmit-queue (atq). The real difficulty is coding a test
+to see if the transmit window is used up and to send the queue
+when space in the window becomes available.
+As I have no network layer that can generate a continous flow of pdus it is
+difficult to simulate a remote busy condition and hence to test the code
+to handle it.
+ 
+4. A simple flow control algorithm, steering the size of the transmit
+window would be nice to have.