Author Topic: Web Server not responding  (Read 6570 times)

Offline johnr

  • Jr. Member
  • **
  • Posts: 91
    • View Profile
Web Server not responding
« on: October 17, 2007, 02:36:23 PM »
Hi, I've been testing my new web page overnight for the last 2 nights
and when I come back in the morning  the browswer is hung in a "Cannot
find server" screen. I can still ping and FTP the board at this point, but can't access any web page. This has happened before I included the floating point library in the project and afterwards.
 My test page uses "<meta http-equiv="refresh" content="20">"  to
refresh the page every 20 secs. I've tested the page during the day
and it looks OK, displaying the proper values etc.
 I made the changes in the web server code to supports 5 char £xxxx
sequences and every page looks OK. The code I added in webinterface.c
in fcInsertString() to handle my new page is

Code: [Select]
case 'W': //  ADC Raw
iChan=*ptrBuffer;
iChan-='1';
cPtr = fnDebugDec( (long)ADC_Chans[iChan].Raw, 0, cValue);
*usLengthToSend = (cPtr - cValue);
break;

case 'Z': // ADC Min
iChan=*ptrBuffer;
iChan-='1';
         cPtr = fnDebugDec( (long)ADC_Chans[iChan].Min, 0, cValue);
    *usLengthToSend = (cPtr - cValue);
break;

case 'H': // ADC Max
iChan=*ptrBuffer;
iChan-='1';
        cPtr = fnDebugDec( (long)ADC_Chans[iChan].Max, 0, cValue);
    *usLengthToSend = (cPtr - cValue);
break;

case 'T': // ADC AlarmLo
iChan=*ptrBuffer;
iChan-='1';
cPtr = fnFltToStr(ADC_Chans[iChan].AlarmLo, cValue);
    *usLengthToSend = (cPtr - cValue);
break;


case 'G': // ADC AlarmHi
iChan=*ptrBuffer;
iChan-='1';
          cPtr = fnFltToStr(ADC_Chans[iChan].AlarmHi, cValue);
*usLengthToSend = (cPtr - cValue);
break;

case 'Q': // ADC AlarmState
iChan=*ptrBuffer;
iChan-='1';
          cPtr=uStrcpy(cValue,aAlarmStates[ADC_ChansiChan].AlarmState]);
         *usLengthToSend = (cPtr - cValue)-1;
break;


 Looking at the memory stats before and after it hangs shows
     Free heap = 0x0af4 from 0x4c00
     Unused stack = 0x2823
 so that looks OK.

 I can try refreshing a dummy page that doesn't do any
dynamic processing overnight and see what happens. I've been running
my regular page for 3.5 hours this morning so far and it hasn't
failed yet. I've been running these tests from the CW debuger.


Here's my string <--> float functions, but the web hung before used these

Code: [Select]
float fnStrToFlt(char* aStr) {
// Convert a non terminated string to a float. Limited to 1 dec place

float Result=0;
int i,Frac=0;
int Mult=1,Len;
int DecPlaces=0;
char* pEnd=aStr;
char* pDec=NULL;

  while (((*pEnd>='0') && (*pEnd<='9')) || (*pEnd=='.') ) {
// Find the end of the str
if (*pEnd=='.')
  pDec=pEnd;  // Remember decimal place
pEnd++;
  }
  Len=pEnd-aStr;
  if  (pDec)
DecPlaces=pEnd-pDec-1;

  while (DecPlaces>1) {
// Limit to 1 dec place
pEnd--;
Len--;
DecPlaces--;
  } 

  while (Len-->0) {
--pEnd;
if (DecPlaces>0) {
  if (*pEnd!='.')
Frac=((*pEnd)-'0');
  pEnd--; // Skip dot
  DecPlaces--;
  Len--;
}
else {
  i=((*pEnd)-'0');
  i*=Mult;
  Result+=i;
  Mult*=10;
}
  }
  if  (Frac>0)
Result+=(float)Frac/10; 
return(Result);
};


char* fnFltToStr(float aFlt, char* aStr) {
// Convert a float to a non terminated string. Return
// a pointer to the next char posistion that would have
// been written. Len of the string=cp-aStr. Limited to 1 dec
// place 

int i=(int) aFlt; // Chop off fraction
float f=aFlt-i; // Fraction
char* cp;

cp=fnDebugDec(i,0,aStr); // int part
*cp++='.'; // decimal point
if ((f*=10)) {
if ((int) (f*10)>=5)
  f+=.1;

}
i=(int)f;
cp=fnDebugDec(i,0,cp); // fractional part
return(cp);
}

 Thanks,
 John

« Last Edit: October 17, 2007, 06:13:11 PM by johnr »

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3188
    • View Profile
    • uTasker
Re: Web Server not responding
« Reply #1 on: October 17, 2007, 07:03:13 PM »
Hi John

Are you using the new fast serving support (#define HTTP_WINDOWING_BUFFERS 2) ? This is still experimental and there is one bug fix which should be used:
http://www.utasker.com/forum/index.php?topic=40.msg175#msg175

If you are using it, you may like to disable it to ensure that the server is then stable (remove the define).

If you get the message that the web server could not be contacted but you can ping the board I expect that it is being caused by a problem with the socket. Look to see whether a TCP RST is returned when trying to contact it. If this is the case I can then give more details about how to find the cause.

Regards

Mark

Offline johnr

  • Jr. Member
  • **
  • Posts: 91
    • View Profile
Re: Web Server not responding
« Reply #2 on: October 17, 2007, 09:38:58 PM »
Hi Mark, Yes, #define HTTP_WINDOWING_BUFFERS 2 was set.
I made all the changes in the release note pertaining to our usage
and will test it out tonight.


 Thanks,
 John

Offline johnr

  • Jr. Member
  • **
  • Posts: 91
    • View Profile
Re: Web Server not responding
« Reply #3 on: October 18, 2007, 02:39:39 PM »
Hi Mark, I ran it overnight and saw the "Cannot
find server" screen, but was able to manually refresh it and it looks ok now. I was able to ping it all night with 0 packet loss.

 John

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3188
    • View Profile
    • uTasker
Re: Web Server not responding
« Reply #4 on: October 18, 2007, 03:00:03 PM »
Hi John

This is as I would expect with the correction on SP5 errata page. It is still possible to lose the connection but it is no longer blocked afterwards and so a manual refresh gets it going again.

In my development version the reason for the single loss of connection has also been worked around (it happens when the client responds rather faster than normal in a local network and sends only a partical ack). I am presently working on a futher optimisation which saves (unnecessary) short TCP frames when serving a page and so this development is still in the 'experimental phase'.

If you need the latest code before it is integrated in a SP or as errata (less likely due to the magnitire of the changes) just send me an email. Otherwise if robustness has priority over speed, removing HTTP_WINDOWING_BUFFERS should also completely avoid the occasional loss.

Regards

Mark