Re: [mpls-linux-general] ldp_socket_tcp_write

[James R. L. <jl...@mi...>]

Are you using the CVS version?  Off the top of my head I can't remember if
I handled this in the ldp-portable library correctly or not.  I don't
think so.  I'm not sure what the correct thing to do is.  The only way to
truly handle this would be to recognize that the socket is not accepting
data.  Add it to the write-fd list so we are notified when it is availble
for writing.  But What do you do with the buffer in the meantime?  How log
do you hold on to it?  How many times do you retry?

The simple answer is to treat it as a critical error and shut down the
session.  If this happens simply because the amount of data being sent
(lot of label mapping) is so large, then maybe packet pacing is needed.

My gut reaction is that these are all detail s that should be left in the
porting layer.  So with that, maybe a PDU queue(s) needs to be created
in the linux porting layer that drains at a specific rate by utilizing
a timer.  It can handle the write failure cases then.  This introduces
all sorts of complication though. ugh.

If you're interested in implementing a fix for this, let me know.  I'd be more
then happy to discuss different solutions with you.

Jim

On Fri, Oct 19, 2001 at 10:05:45AM -0700, Scott Lee wrote:
> Should ldp_socket_tcp_write() handle cases
> where write() system call returns number of
> bytes written which is less than the number of bytes
> requested? This is a normal situation where kernel 
> cannot accept the entire buffer requested to send.
> 
> Has anyone experience problem with not able
> to send the entire packet because of some
> kind of congestion in the link?
> 
> Thanks.
> 
> Scott
> 
> __________________________________________________
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com
> 
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general

-- 
James R. Leu