Hi All,

mijn client server applicatie kan werken in twee modi:
1) een richting - alleen client stuurt ber naar de server
2) twee richtingen - server geeft 'antwoorden' aan opdrachtgever.

bij het programma te starten in de eerste modus lijkt het OK, maar als antwoorden op de client-server toepassingen dan de klant afrit de werking ervan na een korte tijd. Ik ben op zoek naar het probleem, maar sommige taugh tijd.

Dit is de functie die de gegevens in de client leest (in die ik heb problemen):

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);
}

Nou, ik weet niet het antwoord op de eerste vraag, maar ik waarschijnlijk gevonden uit het antwoord voor de seconf een. de reden waarom het programma kreeg gekke is dat sinds het multi threading er een situatie waarin een gebeurtenis wordt opgeworpen die het systeem om freak out veroorzaken. Ik heb nog niet hebben gevonden waarom het freaks out, maar als ik voorkomen dat het evenement worden verhoogd dan houtkap is OK en client-toepassing is niet de werking ervan te verlaten.

Ik zal al blij als iemand kon beantwoorden mijn eerste vraag hierboven - waarom is de lengte van de buffer \u003d 0? zou het zijn omdat ik in mijn memcpy coderen / decoderen buffer functies?

Thanks again,
Lenna

Hallo Lenna,

Het is een complexe aanvraag, en de problemen kunnen worden op verschillende plaatsen dus gebruik debugger om de exacte reden te onderzoeken. Toch Ik heb wat code opmerkingen:

1. Over "TCPClient:: readSocketData"
Als de externe kant sluit de socket voor het schrijven van (shutdown de socket) of sluit het.
dan de functie "recv" geeft 0

Zie man recv
"Het rendement waarde 0 wanneer de peer heeft een ordelijke shutdown uitgevoerd."

Deze methode zal verlaten op het tweede terugkeer omdat "br" zal worden 0 en de terugkeer waarde 0. Dus Alle gegevens in de buffer wordt helemaal niet aangeraakt.

Ik heb ook een kijkje op de gebruiken errno en # include <errno. h> de controle van de fout na elke mislukte system call. Ik recomment u om fouten te controleren.

2. In gedachten hebben dat als je zowel de client als de server testen op dezelfde machine (localhost) het verlaten van de cliënt met beëindigde aansluiting zorgt ervoor dat de server te ontvangen SIG_PIPE signaal. Dus ik raden u aan om dat signaal te blokkeren op de server.

3. De methode "BrainControlComData:: decodeMsg (char * decodeUnifiedMsgForServer)" heeft geen idee over de buffer lengte.

char * is een pointer naar een byte of byte volgorde

Ik recomment u om deze verklaring te wijzigen

BrainControlComData:: decodeMsg (const char * decodeUnifiedMsgForServer, size_t grootte)

Dat is waarom deze lijnen ziet er vreemd uit:

if (strlen (decodeUnifiedMsgForServer) \u003d\u003d 0)
(
char * error \u003d "waarschijnlijk een fout (zie hieronder Q1)";
)


Ik veronderstel dat decodeMsg gewoon niet de buffer met de juiste lengte te krijgen, En het geen enkele controle uit te voeren over de juiste lengte. Het gaat ervan uit dat alles OK is, en wanneer dat niet het geval is krijg je vreemde resultaten.

De memcpy is niet nodig
int Web_lenOfClass;
/ / Decode len van MSG
memcpy (& Web_lenOfClass, msg, grootte);
int lenOfClass \u003d nthol (Web_lenOfClass);


Je zou kunnen vervangen door:
int lenOfClass \u003d ntohl (* (uint32_t *) msg);

en ook
int msgid \u003d ntohl (* (uint32_t *) (msg + MSG_ID_LOCATION));


4. Als je tijd hebt zou ik een kijkje op de unit tests maken (test in isolatie) over elk belangrijk klasse / methoden. En om te controleren ze zorgvuldig. Meer tests met meer nauwkeurige tests.


Met vriendelijke groet
O.