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

Re: [Q] About block/nonblock TCP Sending in ns2



John:

	Thank you for your answer. I agree with you NS2
dont have threads. But I think in the TCP layor, it is
in fact has a "infinate buffer" which means whenever appliication
layor "send()" message to Tcp layor, it will simply "buffer"
the data in the buffer (of course, only moving pointer, no
real data copying needed). The following is a little analysis,
hope to get some wisdom from you:

-------------------Ns 2 Tcp Application buffer-----------------------

 I've searched through some related code in ns2.  It looks like their Tcp
application doesnt implement a application buffer for packets sending
(equals to the buffer for socket in real OS). What they do is roughly like
this: 
		(refer to "tcp-full.cc")
       1) Whenever application wants to send n bytes just advance a
pointer in TCP protocol called "curseq_" for n bytes

        2) Compute the highest byte could be sent by: 

        int win = window() * maxseg_;  // window() in pkts

        int topwin = curseq_; // 1 seq number past the last byte we can send
        if ((topwin > highest_ack_ + win) || infinite_send_) 
                topwin = highest_ack_ + win; 

        3) Try to send out all bytes below "topwin", the link layer is
said to do some buffering, but that is obvious not the "buffer" we meant. 
               Based on above, it seems that if the application layor
sending much faster than the link layor can adopt, the pointer "curseq_"
will increase much faster than the "highest_ack_ + win", and the
difference between curseq_ and "highest_ack_+win" is equal to the socket
buffer size in real world. If we define this difference as AppBufSize,
then AppBufSize can go infinately large in the simulator (considering that
in simulation, they don't really buffer packet content, so this
implementation is obvious the easist, just advance a pointer)  which means
the Application buffer is infinately large. 
	So, NS2 doesnt need to "block" message sending call at all
since it has an infinate buffer conceptually and can buffer the 
message sent anyway no matter how fast upper layor inject the messages.




Thanks,


Kaichuan