Discussion :

[jonzuzu]

salut,

j'ai r�alis� un tuyau entre un client TCP sur pocket PC et un serveur TCP sur PC.
Apres a voir envoy� un message vers le serveur PC, je souhaite directement dans le OnReceive() du serveur renvoyer un message de confirmation de bonne reception...
Le Send(...) a l'air de bien se d�rouler car il me retourne le bon nombre d'octets envoy�s mais la fonction OnReceive() cot� client TCP sur PDA n'est jamais notifi�e (je l'ai bien sur surcharg� au pr�alable...)
voil� ma methode OnReceive() du serveur TCP sur le PC:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
CAsyncSocket::OnReceive(nErrorCode);
 
	char MsgRecu[2096]; // définition du buffer
	int iVitesse = 0;
	int iTaille = Receive(MsgRecu, 2096); // Réception qui retourne le nombre d'octets reçus	
	MsgRecu[iTaille] = '\0';
char cPort[4];
		for (int i = 1 ; i <= 4 ; i++)
		{
			cPort[i-1] = MsgRecu[i];
		}		
		m_uiPortEcouteClient = atoi(cPort);
		m_sImmatriculation = &MsgRecu[i];
 
		//Ajout du nouvel usager dans la liste et dans l'arbre				
		((CMainFrame*) m_pMainFrame)->AjouterUsager( this);		
 
		char* cBuffer;
		CString sBuffer;
		sBuffer = "Détection OK";
		cBuffer = sBuffer.GetBuffer(0);
		int iTaille = sBuffer.GetLength();
		int j = this->Send(cBuffer,iTaille);

Et pour la r�ception j'ai juste mis un breakpoint dans la fonction OnReceive() mais je n'y vais jamais...

Donc si quelqu'un pense pouvoir m'eclaircir ca serait cool

[farscape]

salut,
je suppose que :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
 
CAsyncSocket::OnReceive(nErrorCode);

le ; c'est une erreur de recopie ?
la signature exact c'est :

CAsyncSocket::OnReceive
virtual void OnReceive( int nErrorCode );

l'objet qui recoit il est initialis� ? le handle m_hSocket est valide (<> NULL) ?

[jonzuzu]

Non mais le bout de code que j'ai mis fonctionne tr�s bien vu que je re�ois bien ma donn�e, c'est dans la derni�re ligne du code au niveau du "Send()" et surtout de la reception de ce Send de l'autre cot� du tuyau qu'est le probl�me.
Le "Send()" me retourne bien le nombre d'octets envoy�s (ici 12), mais cot� Pocket PC je suis pas notifi� sur le OnReceive()
Voila la m�thode OnReceive() cot� Pocket PC que je surcharge dans la classe CSocketClientTcp.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
 
void CSocketClientTcp::OnReceive(int nErrorCode) 
{
	CCeSocket::OnReceive(nErrorCode);
                char buf[100];
                Receive (buff,100); 
}

Pour ce qui est de l'erreur que tu signale sur la syntaxe du OnReceive(), je n'ai fait qu'impl�menter la m�thode grace au Class Wizard donc la syntaxe est la bonne, surtout que ce n'est pas la rpemi�re fois que je l'implante.

[jonzuzu]

toujours pas d'aide possible sur mon post?
n'h�sitez pas en tout cas, parce que l� je gal�re enorme.
je vous explique rapide l'algo de mon appli:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
   Monde PC                           Monde Pocket PC
 
Creation Client UDP------------->> Serveur UDP
et envoi                               |--> OnReceive()
Creation Serveur TCP                       {
                                                .....
                                                Création Client TCP et envoi 
                                                Send()
                                             }               |
Réception dans Serveur TCP <<--------------------------------|
OnReceive()
{
...
Send()    // (envoi au client TCP déjà créé)
} |
  |--------------------------------------------> OnReceive() du client TCP
                                                               Méthode surchargée dans la classe Client TCP déjà instanciée.

Le probl�me se situe en fait dans la derni�re transmission, de l'envoi du serveur TCP vers la reception du client TCP.
L'envoi ne retourne pas d'erreur et retourne le bon nombre d'octets envoy�s mais la m�thode OnReceive() du client TCP n'est jamais appel�e...