Hi All,

min klient-server-program kan arbejde i to tilstande:
1) en retning - kun klienten sender beskeder til serveren
2) to retninger - server giver svar "til kunden.

når programmet kører i første tilstand, det ser OK ud, men når serveren svar til kunden end kundens ansøgning forlade sin drift efter et kort stykke tid. Jeg forsøger at finde problemet, men har nogle taugh tid.

dette er den funktion, der læser data i klientsiden (som jeg har problemer):

int TCPClient::readSocketData(int s,
              char *decodeUnifiedMsgForServer,			
              int n,			
	 bool& isMsg
             )
{
	int bcount;							int br;							
	bcount = 0;
	br = 0;
	while (bcount < n)					
	{
		if ((br = recv(s,decodeUnifiedMsgForServer,n-bcount,0)) > 0)
		{
			isMsg = true;
			bcount += br;							decodeUnifiedMsgForServer+= br;              
		}
		else if (br < 0)             /* signal an error to the caller */
		{
			return(-1);
		}
		else							             {
			return bcount;
		}
		//Y 17_04_05 -
		Sleep(0);
		//Y.
                   }
  return(bcount);
}

void BrainControlComData::decodeMsg(char* decodeUnifiedMsgForServer)
{



	if(strlen(decodeUnifiedMsgForServer) == 0)			
             {
		char* error = "probably an error (see Q1 below)";
	}


	char* msg = decodeUnifiedMsgForServer;
	int size = 4;

	int lenCursorData;
	int lenManipData;
	int lenVzData;

//places 1 - 12 in msg are reserved for total size/ isEventMsg/ MsgID

	int Web_lenOfClass;					
// decode len of msg
	memcpy(&Web_lenOfClass, msg, size);
	int lenOfClass = ntohl(Web_lenOfClass);

	int Web_MsgID;						
// decode msg ID
	memcpy(&Web_MsgID, msg + MSG_ID_LOCATION, size);
	int msgID = ntohl(Web_MsgID);



	//Y 6_07_05 -
	int counter = 12;

	int len = 0;
	len = comData[CURSOR_DATA]->decodeMsg(msg + counter);
	counter += len;

	len = comData[STATE_DATA]->decodeMsg(msg);
}

godt, jeg ikke kender svaret på det første spørgsmål, men jeg nok fundet ud af svaret til seconf en. grunden til, at programmet fik skøre er, at eftersom det er multi threading er der en situation, hvor en begivenhed er rejst, og som forårsager, at systemet flipper ud. Jeg har stadig ikke fundet, hvorfor den freaks ud, men hvis jeg forhindre begivenheden, der skal rejses end skovhugst er OK, og klient applikation ikke forlade sin drift.

Jeg vil blive glad for selv, hvis nogen kunne besvare mit første spørgsmål ovenfor - hvorfor er længden af buffer \u003d 0? kunne det være fordi jeg bruger memcpy i min kode / afkode buffer funktioner?

Tak igen,
Lenna

Hej Lenna,

Det er et komplekst program, og de problemer, der kunne være på forskellige steder, så brug debugger til at undersøge den præcise årsag. Men jeg har lavet noget kode bemærkninger:

1. Om "TCPClient:: readSocketData"
hvis den eksterne side lukker soklen til at skrive (shutdown stikket) eller lukker den.
derefter funktionen "recv" giver 0

se man recv
"Afkastet er værdien 0, når peer har udført en ordentlig lukning."

Denne metode vil ud på den anden tilbage, fordi "br" vil være 0 og afkastet værdien 0. Så vil Alle data i bufferen ikke rørt ved alle.

Jeg vil også anbefale dig at bruge errno og # include <errno. h> for at tjekke fejl efter hver fejlbehæftet system opkald. Jeg recomment dig til at tjekke fejl.

2. Har i tankerne, at hvis du tester både klient og server på samme maskine (localhost) forlader klienten med uafsluttede socket får serveren til at modtage SIG_PIPE signal. Så jeg anbefale dig at blokere for, at signalet på serveren.

3. Metoden "BrainControlComData:: decodeMsg (char * decodeUnifiedMsgForServer)" har ingen idé om buffer længde.

char * er en pointer til en byte eller byte sekvens

Jeg recomment dig til at ændre denne erklæring

BrainControlComData:: decodeMsg (const char * decodeUnifiedMsgForServer, size_t størrelse)

Det er grunden til disse linjer ser mærkeligt ud:

if (strlen (decodeUnifiedMsgForServer) \u003d\u003d 0)
(
char * error \u003d "sandsynligvis en fejl (se nedenfor Q1)";
)


Jeg formoder, at decodeMsg simpelthen ikke får den buffer med korrekte længde, og det gør ikke nogen kontrol over den korrekte længde. Det forudsætter, at alt er OK, og når det er ikke sandt, du får mærkelige resultater.

Den memcpy er ikke nødvendig
int Web_lenOfClass;
/ / Afkode len af msg
memcpy (& Web_lenOfClass, msg, size);
int lenOfClass \u003d ntohl (Web_lenOfClass);


Du kan erstatte det med:
int lenOfClass \u003d ntohl (* (uint32_t *) msg);

og også
int msgid \u003d ntohl (* (uint32_t *) (msg + MSG_ID_LOCATION));


4. Hvis du har tid, vil jeg anbefale dig at oprette enhed test (test i isolation) om hver vigtig klasse / metoder. Og for at se dem mere grundigt. Flere forsøg med mere præcise tests.


Venlig hilsen
O.