Socket et protocole UDP, ne lire que la dernière donnée reçue

Version imprimable

Voir 40 message(s) de cette discussion en une page

26/12/2013, 14h10
minnesota

et il y a aussi les mutex anonymes si je me souviens bien... mais bon, c'est dans le principe, après, dans le genre y'a probablement plus adapté... et encore, faut voir comment c'est géré en interne... je me rappelle de sessions de "profiling" plutôt étonnantes...

Sinon, est-ce qu'un "closesocket" serait susceptible de réinitialiser ce fameux "buffer matériel" ?
26/12/2013, 14h23
Auteur

La fermeture de socket videra sans doute le buffer. Mais j'aimerai éviter d'enchainer les ouvertures / fermetures de socket pour récupérer 1 donnée.

Salut,

J'ai fait un petit break que du coup j'ai occupé à faire un client et un serveur UDP sur localhost, plutôt des prototypes on va dire. L'exercice était intéressant. Alors comme j'ai pu expérimenter la chose, j'ai une solution possible et très simple qui vise à resynchroniser la communication. Pour cela, j'ai mis en oeuvre un "timer" qui mesure le temps écoulé après l'appel bloquant "recvfrom", je précise que l'opération a lieu dans une une boucle "do-while" et qu'il n'y a pas de "thread" ou de "mutex" dans cette ébauche. Donc je disais, je mesure le temps écoulé, s'il est trop petit (éventuellement par rapport à la fréquence d'envoi du client), alors la donnée provient du buffer de la carte réseau, à l'inverse, c'est une donnée fraichement reçue.

voilà le pseudo-code :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 do { time start; recvfrom(&data); if (error) break; else time stop; if ((stop-start)<x_milliseconds) continue; //dépiler... do_action(data) } while (statement)
J'ai pas les codes sources sous la main, mais s'il y en a qui les veulent, ou les exe des prototypes, faites-moi signe...

re,

Une autre approche sur le même principe, mais sans timer cette fois-ci. J'ai pas fait de mesure, mais ça fonctionne.

J'avais d'abord voulu faire du "peeking", mais ça ne donnait pas le résultat escompté. C'est une option de "recvfrom" (MSG_PEEK) mais contrairement à mon attente, l'appel reste bloquant. J'ai donc fouillé un peu msdn en ce sens à chercher quelque chose de compatible avec UDP, et j'ai trouvé un bon candidat en la fonction "ioctlsocket".

Avec les bons paramètres, "ioctlsocket" donne la quantité de données dans la file d'attente du buffer du socket. Donc, ce que je fais, je vide le buffer jusqu'à ce qu'il n'y a plus de données en attente de traitement, ainsi, je libère le buffer du socket pour recevoir une donnée fraiche.

Son implémentation dans le code dépendra du degré de fraicheur recherché :aie:

Je reprendrai peut-être son expérimentation la semaine prochaine si j'ai le temps...

En deux lignes, voilà à quoi ça ressemble en tout cas, si ça peut t'aider ;)
Code:

1 2 3 4 u_long socket_pending_data= 0; if (::ioctlsocket(socket_file_descriptor, FIONREAD, &socket_pending_data)==NO_ERROR) if (socket_pending_data) // ou if (socket_pending_data>freshness_limit) ...

28/12/2013, 11h52
Auteur

Merci, je mets ça de côté jusqu'à la rentrée. Je ne connaissais pas ioctlsocket
:hola:

J'ai fait ceci mais je trouve le code moche à cause de la fonction Sleep :? :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
void MyClass::lock()
{
	dataLock = false;
	dataUpdated = false;
	while (!dataUpdated)
	{
		Sleep(2);
	}
 
	dataLock = true;
}
 
void MyClass::unlock()
{
	dataLock = false;
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
DWORD MyClass::readDataFrom()
{
	int sinSize;
	int len;
	info recvData;
 
    fd_set fd;
    timeval tv;
 
 
    sinSize = sizeof(sin);
    len = 0;
 
	if (socketError == NO_ERROR)
	{
		while(!stopReading)
		{
			FD_ZERO(&fd);
			FD_SET(socketServer, &fd);
 
			tv.tv_sec = sec;		// timeout sur la méthode accept
			tv.tv_usec = usec;
 
 
			if (select(0, &fd, NULL, NULL, &tv) > 0)
			{
				len = recvfrom(socketServer, (char*)&recvData, sizeof(recvData), 0, (SOCKADDR *)&sin, &sinSize);
 
				if (!dataLock)
				{
					dataLen = len;
					if (len > 0)
					{
						data.id = recvData.id;
						data.time = recvData.time;
						data.x = recvData.x;
						data.y = recvData.y;
						data.z = recvData.z;
					}
				}
			}
			dataUpdated = true;
		}
	}
 
	dataLen = 0;
 
    return 0;
}

13/01/2014, 23h06
minnesota

Salut Auteur,

Là c'est un problème de "design"... Pour les lock/unlock il faut que ça soit des opérations atomiques, mais si tu cherches un minimum de synchronicité entre tes "threads", mieux vaut jouer avec les signaux/événements... une api genre WaitForSingleObject (quelque chose comme ça, je suis pas sûr de la dénomination exacte) peut t'aider. Cependant, après vient la question du pourquoi faire un "thread" de lecture et un thread de calcul si tu peux faire tout dans un seul ?

Une dernière chose, lorsque je me suis intéressé à ton problème l'année dernière :aie:, il m'a semblé, de souvenir, que la méthode "accept" n'était pas prise en charge par UDP, pourtant tu l'utilises...
14/01/2014, 10h47
Auteur
La notion atomic n'existe pas sous Visual Studio 2010 :( car elle est apparue avec le C++11 je crois.

Citation:

Envoyé par minnesota

Cependant, après vient la question du pourquoi faire un "thread" de lecture et un thread de calcul si tu peux faire tout dans un seul ?

Le code est intégré dans une DLL. Pour éviter de bloquer le programme principal, j'ai dû créer un thread qui ne contient que la fonction readDataFrom(). Le programme principal appelle les fonctions lock et unlock() en plus de getters (getId(), getX(), getY(), getTime()).

Le schéma de fonctionnement du programme principal est le suivant :
1. lock()
2. getId(), getTime(), getX, getY(), getZ()
3. unlock()
4. traitement des données lues
Citation:

la méthode "accept" n'était pas prise en charge par UDP, pourtant tu l'utilises...

il ne me semble pas voir de restrictions dans la doc :
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx
ou alors j'ai mal compris.
14/01/2014, 13h30
jblecanard

Salut

Citation:

Envoyé par Auteur

La notion atomic n'existe pas sous Visual Studio 2010 :( car elle est apparue avec le C++11 je crois.

En effet !

Je vais dévier un poil du sujet, mais puisqu'on parle de synchronisation de threads et de lecture de socket, pourquoi ne pas faire de l'asynchrone ? Comme ça plus de mutex, plus de dead-lock, meilleurs perfos. Mais je suppose que t'es trop avancé dans ton projet pour penser à une refonte maintenant, dommage.
14/01/2014, 20h01
Auteur

Citation:

Envoyé par jblecanard

Je vais dévier un poil du sujet, mais puisqu'on parle de synchronisation de threads et de lecture de socket, pourquoi ne pas faire de l'asynchrone ?

Intéressant comme approche. Comment procèderais-tu ? Peux-tu me donner une exemple de code ?
14/01/2014, 22h36
minnesota

Non :aie: atomique dans le sens très bref, qui se rapproche le plus possible d'une instruction processeur... Il ne faut pas que ta fonction contienne des "sleep" ou truc comme ça. Il faudrait peut-être même faire du "inline" mais je ne sais pas si c'est toujours d'actualité ça...

À côté, ben c'est déjà de l'asynchrone si je ne m'abuse, sauf que pour avoir la dernière donnée envoyée comme tu le souhaites, il faut que tu te synchronises ou resynchronises un peu... Il a été proposé plusieurs méthodes qui au pire te donnent une donnée de retard, mais vu ton bout de code, je me demande si t'en as retenu une... Pour rappel, il y avait la piste du conteneur LIFO, je rajouterais que si en plus il est cyclique ça devrait être pas trop mal (je sais pas si je l'ai déjà dit ou pas), et le purgeur de la file d'attente qui te garantit une donnée fraiche.

Pour développer un peu plus pour le conteneur cyclique, tu le remplis et tu tiens à jour un index de la position courante. Si ton conteneur est suffisamment grand, et je suppose que tout se fera sur un seul processeur ou coeur, alors la lecture d'une donnée se ferait sans risque de collision avec l'écriture et vice versa.

Pour "accept", même si effectivement la doc MSDN est plus orientée sur TCP, du moins je trouve, il me semble que si tu gères correctement les erreurs API, tu devrais en avoir une si tu tentes d'utiliser "accept" avec UDP. À voir en tout cas... J'ai eu qu'une unique expérience :aie: sur la question, donc je ne saurais être catégorique...
15/01/2014, 16h23
jblecanard

Salut !

Si tu dois synchroniser deux threads pour que l'un puisse lire une donnée dans l'autre, alors tu n'es plus asynchrone.

Citation:

Envoyé par Auteur

Le code est intégré dans une DLL. Pour éviter de bloquer le programme principal, j'ai dû créer un thread qui ne contient que la fonction readDataFrom(). Le programme principal appelle les fonctions lock et unlock() en plus de getters (getId(), getX(), getY(), getTime()).

Mince j'avais pas vu ça. Es-tu également l'auteur de ce programme ou dois-tu fournir la DLL qui respecte l'API imposée ? Si oui, il n'y a rien que techniques asyncrhones ne puissent faire, l'usage de lock()/unlock() est intrinsèquement un mécanisme de synchronisation. J'attendrais la réponse à ma question avant de suggérer quelque chose :)
15/01/2014, 19h15
minnesota

Citation:

Envoyé par jblecanard

Si tu dois synchroniser deux threads pour que l'un puisse lire une donnée dans l'autre, alors tu n'es plus asynchrone.

Se synchroniser par rapport à la file d'attente du "buffer udp de la carte réseau" :aie: ... il faut que tu lises ou relises la discussion, au moins pour pas que tu perdes du temps dans une mauvaise direction par rapport au besoin ... Sinon, deux méthodes proposées sont bien asynchrones, threads parlant, tout au moins une, l'autre n'a pas besoin d'être "parallélisée". D'où mon étonnement dans mon précédent message de voir encore du lock/unlock, entre autres.
16/01/2014, 15h11
jblecanard

Salut

Citation:

Envoyé par minnesota

Se synchroniser par rapport à la file d'attente du "buffer udp de la carte réseau" :aie: ... il faut que tu lises ou relises la discussion, au moins pour pas que tu perdes du temps dans une mauvaise direction par rapport au besoin

J'ai relu et oui j'ai bien compris :) Tes propositions sont recevables mais sont néanmoins synchrones, puisqu'on n'a qu'un thread et qu'il y a des appels bloquants. Il n'y pas le choix de toute façon : les sockets n'offrent pas d'interface asynchrone, on peut au mieux faire des read non bloquants mais c'est pas la panacée.

Pour moi ici, il y a un quelque chose qui n'est pas clair, à savoir la notion de donnée "fraîche". Quand je parle d'asynchrone, et au regard de ce que j'ai compris du besoin, je pense à :
- Un thread qui lit les données en continu tant qu'elles sont disponibles et stocke la dernière reçue. C'est lui qui se tape l'attente et les appels bloquants.
- Un thread applicatif qui envoie une demande pour avoir la donnée (appel non bloquant) et effectue un traitement lorsqu'il la reçoit.

Après j'ai peut-être mal compris le besoin, mais dans ce cas, une clarification d'Auteur serait la bienvenue. J'ai l'impression que ce sera synchrone par design.

PS: Les sleep c'est mal, un chaton est tué à chaque appel.
16/01/2014, 16h17
minnesota

Ah salut,

Ben si t'as bien compris, je crois.

Sinon pour du "read" non bloquant, quand j'avais testé vite fait, disant expérimenté, parce que j'avais encore jamais utilisé les sockets, il me semble que ça retournait tout le temps la même donnée, et quand le "buffer de la carte" était vide, ben ça redevenait bloquant. C'était une option avec MSG_PEEK, quelque chose comme ça, faut voir un message précédent, ben juste au-dessus, tiens.

Sinon pour ton deuxième paragraphe ça a été proposé aussi. Après pour ce qui est du nombre de "threads" ça va dépendre de son interface, mais tu conviendras que les principes et les grandes lignes sont là.

Du coup, avec le nouveau message, jblecanard, on connait toujours pas la direction prise, et pour rebondir sur le chaton, on a juste j'ai mis un "sleep" mais c'est moche :aie:

http://images-00.delcampe-static.net...35_002.jpg?v=9

Auteur, revient à la maison :P

De toute façon, jblecanard, pour le trouver, c'est simple, soit il est dans l'espace (hAuteur), soit il est dans la taverne, soit il est dans la taverne, soit il est dans la taverne, soit il écrit un livre :mouarf:
16/01/2014, 17h02
jblecanard

Ha ha !

Citation:

Envoyé par minnesota

Sinon pour ton deuxième paragraphe ça a été proposé aussi.

Pas tout à fait ! Ce qui est proposé, c'est:
- Un thread qui lit les données en continu tant qu'elles sont disponibles et stocke la dernière reçue.
- Un thread applicatif qui bloque le thread de lecture pour lire la donnée et le débloque ensuite (c'est un appel bloquant).

S'il n'y pas besoin de performances de ouf, un simple mutex autour du getter suffit.
16/01/2014, 17h55
minnesota

mais il y a la variante aussi :aie:

Citation:

Envoyé par minnesota

Pour rappel, il y avait la piste du conteneur LIFO, je rajouterais que si en plus il est cyclique ça devrait être pas trop mal (je sais pas si je l'ai déjà dit ou pas) ../.. Pour développer un peu ../.. tu le remplis et tu tiens à jour un index de la position courante. Si ton conteneur est suffisamment grand, et je suppose que tout se fera sur un seul processeur ou coeur, alors la lecture d'une donnée se ferait sans risque de collision avec l'écriture et vice versa.

non ?
17/01/2014, 10h05
jblecanard

Salut

Là tu proposes le lock-free ring buffer, c'est une bonne idée mais c'est assez compliqué à coder et ça nécessite d'avoir std::atomic_flag.

J'ai revu ma copie (en un mot j'ai réécris mon code :mrgreen:) car je partais dans toutes les directions et cela ressemblait de plus en plus à un code spaghetti :aie: J'ai donc appliqué la méthode de Minnesota :

Citation:

Envoyé par Minnesota

Pour développer un peu plus pour le conteneur cyclique, tu le remplis et tu tiens à jour un index de la position courante. Si ton conteneur est suffisamment grand, et je suppose que tout se fera sur un seul processeur ou coeur, alors la lecture d'une donnée se ferait sans risque de collision avec l'écriture et vice versa.

J'ai choisi la pile. C'est à dire qu'à chaque lecture des données je rempli un tableau. Mes getter vont ensuite lire ce tableau à l'index n-1. Lorsque ce tableau est plein je remets mon compteur à 0. Le contenu du tableau est mis à jour dès qu'une donnée est disponible.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 int sinSize; int len; int id; info recvData; fd_set fd; timeval tv; sinSize = sizeof(sin); len = 0; id = 0; if (socketError == NO_ERROR) { while(!stopReading) { FD_ZERO(&fd); FD_SET(socketServer, &fd); tv.tv_sec = sec; // timeout sur la méthode accept tv.tv_usec = usec; if (select(0, &fd, NULL, NULL, &tv) > 0) { len = recvfrom(socketServer, (char*)&recvData, sizeof(recvData), 0, (SOCKADDR *)&sin, &sinSize); if (len > 0) { dataLen[id] = len; data[id].id = id; data[id].time = recvData.time; data[id].x = recvData.x; data[id].y = recvData.y; data[id].z = recvData.z; id = id + 1; if (id > MAX) id = 0; } } } } for (i=0; i<MAX; i++) { dataLen[i] = 0; }
Ce tableau n'a pas besoin d'être grand, avec MAX = 10, cela fonctionne très bien.

Merci à vous tous pour votre aide :ave:

17/01/2014, 10h55
jblecanard

Attention car tu effectues un accès concurrent sur ton tableau et en particulier ton index id. L'accès à cette variable doit être protégée dans une section critique. Ca peut très bien se passer dans les tests et se casser la figure plus tard à un moment inattendu. Leproblème n'est donc pas rigoureusement résolu :marteau:

Que font les getters quand le tableau est vide ? Ils ne peuvent plus rien lire ?

Voir 40 message(s) de cette discussion en une page