lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Microblaze and lwIP


From: jcr_alr
Subject: Re: [lwip-users] Microblaze and lwIP
Date: Mon, 21 May 2007 10:40:00 -0300
User-agent: Internet Messaging Program (IMP) 3.1

Hi Kieran,

I looked into the use of TCP_NODELAY. If this option is set, the result is to 
add TF_NODELAY to tcp->flags.

In api_msg.c in do_write() this flag is used as shown in the code fragment 
below.

   case NETCONN_TCP:      
      err = tcp_write(msg->conn->pcb.tcp, msg->msg.w.dataptr,
                      msg->msg.w.len, msg->msg.w.copy);
      /* This is the Nagle algorithm: inhibit the sending of new TCP
   segments when new outgoing data arrives from the user if any
   previously transmitted data on the connection remains
   unacknowledged. */
      if(err == ERR_OK && (msg->conn->pcb.tcp->unacked == NULL || (msg->conn-
>pcb.tcp->flags & TF_NODELAY)) ) {
                  tcp_output(msg->conn->pcb.tcp);

In my case tcp->unacked is always NULL (since I am only sending the one set of 
data) so the other condition is redundant. The function tcp_output() would 
normally only send out only the one segment (the first segment which is full) 
since the pcb->lastack will not get updated until the client responds and 
updates this field

      while (seg != NULL &&
           ( (ntohl(seg->tcphdr->seqno) - pcb->lastack + seg->len <= wnd) ) 

In my version the second segment is sent without delay since the flags are now 
set to include TCP_PSH.

     while (seg != NULL &&
         ( (ntohl(seg->tcphdr->seqno) - pcb->lastack + seg->len <= wnd) 
||           (TCPH_FLAGS(seg->tcphdr) & TCP_PSH) )) 

I am not completely sure of my interpretation of the sequence of events and 
would welcome any corrections.

John Robbins.




Quoting Kieran Mansley <address@hidden>:

> On Tue, 2007-05-08 at 15:06 +0100, Kieran Mansley wrote:
> 
> > Unfortunately, this is just a property of TCP, rather than either lwIP
> > or windows having a bug.  I think linux has some clever stuff in it to
> > notice when the delayed ACK protocol would harm performance and so is
> > able to turn it off in cases like this.
> 
> A colleague has pointed out that you may be able to avoid this problem,
> if you're using the sockets API, by setting the TCP_NODELAY socket
> option.  This won't solve the issue in all cases, but may be good enough
> for your needs.
> 
> Kieran
> 
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
> 







reply via email to

[Prev in Thread] Current Thread [Next in Thread]