2009-09-22 5 views
2

Je dois revenir encore une fois aux sockets de Symbian. Code pour établir une connexion à un serveur distant se présente comme suit:Symbian: effacer le tampon de l'objet RSocket

TInetAddr serverAddr; 
TUint iPort=111; 

TRequestStatus iStatus; 
TSockXfrLength len; 

TInt res = iSocketSrv.Connect(); 

res = iSocket.Open(iSocketSrv,KAfInet,KSockStream, KProtocolInetTcp); 

res = iSocket.SetOpt(KSoTcpSendWinSize, KSolInetTcp, 0x10000); 

serverAddr.SetPort(iPort); 
serverAddr.SetAddress(INET_ADDR(11,11,179,154)); 

iSocket.Connect(serverAddr,iStatus); 
User::WaitForRequest(iStatus); 

Au cours de la iSocket je reçois des paquets de taille variable. Sur très peu d'occurrences, il arrive qu'un tel paquet soit corrompu. Ce que je voudrais faire alors est d'effacer toutes les données qui sont actuellement dans le tampon iSocket et prêt à être lu. Je n'ai vu aucune méthode de RSocket qui me permette d'effacer le contenu du buffer. Est-ce que quelqu'un sait comment faire ça? Si possible, je voudrais éviter d'utiliser RecvOneOrMore() ou recv similaire vider la mémoire tampon

Merci

+0

Comment savez-vous que les données sont corrompues? Êtes-vous sûr de ne pas chercher une fonctionnalité qui ne devrait pas faire partie d'une socket TCP? Ne devriez-vous pas ouvrir une seconde prise lorsque le premier canal de communication est compromis? –

Répondre

1

Vous ne devriez pas faire ce que vous demandez. La réception de données corrompues est une indication que l'application à l'autre extrémité est en quelque sorte défectueuse, il s'agit donc d'un problème de couche application, et non d'un problème de couche transport. Vous devriez, dans votre protocole d'application que vous avez construit sur TCP, inclure un message de réponse d'erreur explicite que vous pouvez utiliser dans cette situation pour informer l'autre extrémité de cette situation (si vous essayez une forme de fiabilité). Puisque vous avez apparemment des limites de message spécifiques dans votre protocole d'application, il ne devrait pas être nécessaire de fermer la connexion, il suffit de rejeter le message corrompu en lisant des octets jusqu'à la prochaine limite de message, et de poursuivre normalement le traitement. En outre, effacer le tampon de réception serait une mauvaise chose à faire même si vous pouviez le faire. TCP est un protocole de type byte-stream, donc il n'a aucune idée des limites des messages. À tout moment donné, le tampon de réception contiendra un nombre d'octets dont la correspondance avec les limites des messages d'application n'est pas garantie, ce qui permet de supprimer de nombreux messages corrects et de ne laisser qu'un message partiel pour le message suivant. lis. (C'est, en passant, une erreur commune commise par les programmeurs de réseau débutant, car si votre application ne communique que rarement, il peut sembler que le protocole TCP conserve les limites des messages, mais il ne le fait pas, et à vous avez finalement.)