Re: [lwip-users] Microblaze and lwIP

[jcr_alr]

Thanks for the fast response.

I will bear your comments in mind. In the current case where I have only the 
two segments (one full and one partial) in a given transaction, I don't think I 
can exceed the client window size. I could add a further condition that the 
proposed transmission of x number of segments wlll not exceed the window limit. 
I think I could do this in tcp_write().

The problem, it seems to me, really lies in the overhead that http makes to 
ensure safe communications. It is not really suited to my application - UDP 
would be better if instrument and computer were always on the same network but 
this of course is rarely the case.

I looked briefly into RFC1644, T/TCP, that seemed to attack some of the issues 
in this very assymetrical type of communication. There did not seem to be much 
in the way of support and a lot of messages about potential security(?) risks 
which I don't think would be an issue in our case.

John.


Quoting Kieran Mansley <address@hidden>:

> On Mon, 2007-05-21 at 10:40 -0300, address@hidden wrote:
> > 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.
> 
> Yes, I agree.  It was a colleague who suggested it and I was sceptical
> that it was Nagle that was causing your particular problem, but I
> thought it worth passing on.
> 
> > 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) )
> 
> 
> That's not quite true.  It will send as many segments as it can without
> exceeding "wnd" bytes past pcb->last_ack.  This could be many segments,
> not just one.  
> 
> > 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) )) 
> 
> The problem here is that if the PSH bit is set you're sending segments
> even if you exceed wnd bytes past lastack.  This violates TCP's spec:
> you're only allowed to send a certain number of bytes to a receiver
> (that's what the window is for) until the receiver says "OK, send me
> some more".  At the start of a connection the wnd value might be small,
> but it should quickly increase so you can send many packets in one go
> rather than just one at a time.  By ignoring this, you're bypassing the
> mechanism that TCP uses to try and avoid packet loss, and so while it
> sounds like it's helpful to you in your particular circumstance, it's
> not a safe change to make.
> 
> Hope that helps you understand what's what.
> 
> Kieran
> 
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>