I study this part of lwIP code to understand on which values can be tune to 
reduce the delay to detect an error if peer or network crash.

I have some remarks about that:

- pcb->nrtx is not explicitly initialize in tcp_alloc (we are save by a 
memset). Some TCP pcb's fields are explicitly initialized in tcp_alloc (even 
with 0), some others are not. I will be better to have something a little bit 
more coherent (when you grep a value in the source code to see where it's 
initialized or changed, it helps to get explicit init).


- if we are not in SYN_SENT state, the "rto" is compute with a shift from a 
"tcp_backoff" table. But this table got a fixed size (13), and TCP_MAXRTX is a 
value which can be tune in lwipopts.h (TCP_MAXRTX=12 in opt.h). So, something 
bigger than 12 could cause a crash. I propose to replace...

  pcb->rto = ((pcb->sa >> 3) + pcb->sv) << tcp_backoff[pcb->nrtx];
By...
  pcb->rto = ((pcb->sa >> 3) + pcb->sv) << tcp_backoff[LWIP_MIN(pcb->nrtx, 
((sizeof(tcp_backoff)/sizeof(tcp_backoff[0]))-1)];


- My default lwipopts.h values are:

  TCP_MAXRTX=12 //same as opt.h
  TCP_SYNMAXRTX=6 //same as opt.h
  TCP_TMR_INTERVAL=100 // default is 250 in tcp.h
  TCP_FAST_INTERVAL=TCP_TMR_INTERVAL
  TCP_SLOW_INTERVAL=(2*TCP_TMR_INTERVAL)

- I do some measures with these values (the test is just to connect to a HTTP 
server)

  - With ARP_QUEUEING=0, "connect" to an inline host from the same IP subnet 
take ~2840ms the first time to success, ~0 for next retry
  - With ARP_QUEUEING=1, "connect" to an inline host from the same IP subnet 
take ~0ms each time to success
  - With ARP_QUEUEING=1, "connect" to a offline host from the same IP subnet 
take ~18000ms to return with error. During this time, we can see on the wire 
some ARP request send each ~3000ms (3000 is a "magic" value from tcp_alloc, I 
don't know why this value. RFC?)
  - With ARP_QUEUEING=1, "connect" to a offline host from another IP subnet 
take ~18000ms to return with error. During this time, we can see on the wire 
some SYN packets send each ~3000ms

I would like to know if these values are defined to be RFC compliant? I would 
like to add the possibility to maximized the delay for the connect on a "per 
connection" base (with an option of course, to avoid to increase footprint or 
change default behavior). LWIP_TCP_CONTIMEO?

- If we are connected, and we "write", and the host/network crash, we are 
blocked during ~7min !!! I don't have study in details, but I suppose that 
netconn_write "retry" to send data because the TCP snd bug is full, and that we 
have to do TCP_MAXRTX retries (but each one more spaced due to the 
tcp_backoff). I would like to have SO_SNDTIMEO implemented to avoid such 
problem. No objects? LWIP_SO_SNDTIMEO?


====================================
Frédéric BERNON 
HYMATOM SA 
Chef de projet informatique 
Microsoft Certified Professional 
Tél. : +33 (0)4-67-87-61-10 
Fax. : +33 (0)4-67-70-85-44 
Email : [EMAIL PROTECTED] 
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
BEGIN:VCARD
VERSION:2.1
N:BERNON;Frédéric;;M.
FN:Frédéric BERNON
ORG:HYMATOM SA;Recherche et Développement
TITLE:Chef de projet informatique
TEL;WORK;VOICE:04-67-87-61-10
TEL;WORK;FAX:04-67-70-85-44
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;23;Zone Industrielle=0D=0A175 rue de Massacan;VENDARGUES;;34740;FRANCE;
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:23=0D=0AZone Industrielle=0D=0A175 rue de Massacan=0D=0AVENDARGUES 34740=0D=
=0AFrance
URL;WORK:http://www.hymatom.fr
ROLE:Chef de projet informatique
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20020404T083210Z
END:VCARD
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users

Reply via email to