Discussion :

[Tymk]

Salut,

Je dois implementer, sous windows XP, un protocole de securite a partir des specifications fournies par le constructeur. Mon programme se limite a la communication avec un validateur d'acces (interface supportant scanners retiens, scanners d'empreintes, ...)

La communication se fait par liaison serie RS232 mais je devrais apres la porter sur reseau Ethernet (pour controler plusieurs validateurs d'acces).

Suite a la lecture des 700 pages de specifications et aux tests realises, je peux dire que le protocole n'a plus de secrets pour moi :

Les paquets sont de tailles variables mais l'en-tete contient la longueur du paquet. Bien qu'il semble y avoir un type de paquets qui n'a pas d'en-tete mais dont la taille est fixe.
Les paquets de donnees sont relativement petits. (fixons le relatif a 100 octets)

La connexion est un "3 ways handshake" avec echange de paquets de synchronisation et d'acknowledgement.

Avant de me lancer dans l'implementation, j'aimerais savoir par ou commencer et comment structurer le programme :
Dois-je utiliser une liaison serie en mode synchrone/asynchrone ? Avec ou sans thread de reception ?

La manipulation des paquets via basic_string<unsigned char> est-elle viable ?

Cette structure vous semble-t-elle correcte :

• Une classe RS232 responsable des fonctions de lecture/ecriture sur le peripherique serie. (+/- couche physique)
• Une classe STREAM responsable de la recuperation de l'integralite d'un paquet. (+/- couche liaison de donnees)
• Une classe PROTOCOL responsable de l'exctraction/insertion des informations a recevoir/envoyer. (+/- couche application)

Merci de me faire part de vos conseils.

[r0d]

Bonjour,

quelques conseils en vrac:

-> de fa�on g�n�rale, le mode asynchrone pour le port s�rie est d�conseill� car trop difficile � g�rer et le mode synchrone est suffisant dans l'immense majorit� des cas.

-> g�n�ralement, la m�thode pour l'�criture/lecture utilis�e est la suivant:
--> on envoie une trame (�criture)
--> on lit la r�ponse dans une boucle avec un nombre d'essai d�termin� pour �viter la boucle infinie.

Cette m�thode a l'avantage d�viter d'utiliser un thread (comme toujours, si on peut faire simple, c'est mieux).

-> pour l'utilisation des string, je ne vois pas de probl�me, au contraire. Au niveau le plus bas, tu es tout de m�me oblig� de manipuler des tableaux de char, mais la classe string de la SL fourni tout ce qu'il faut pour passer de l'un � l'autre.

-> ton design me semble bien � premi�re vue. Il est cependant difficile d'en dire plus avec si peu de d�tails.

Si �a peut aider, je te copie une classe que j'utilise souvent pour la couche basse (lecture/�criture sur le port s�rie). Ne fonctionne que pour Windows:

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
// SerialPortManager.h
 
#include <windows.h>
 
class SerialPortManager
{
public:
	SerialPortManager(){}
	~SerialPortManager();
 
	bool	OpenPort( int port );
	void	FlushPort();
	int	Read( unsigned char * buffer, int buffLen );
	void	Write( const unsigned char * buffer, const int buffLen );
	void	ClosePort();
 
private:
	HANDLE m_hCom;
};

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
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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
#include "SerialPortManager.h"
 
#include <sstream>
 
SerialPortManager::~SerialPortManager()
{
    ClosePort();
}
 
bool SerialPortManager::OpenPort( int port )
{	
	std::stringstream device;
	device << "COM";
	device << port;
 
	m_hCom = CreateFile ( device.str().c_str(), GENERIC_READ | GENERIC_WRITE, 0, NULL, 
		OPEN_EXISTING, 0, NULL );
 
	if ( m_hCom == INVALID_HANDLE_VALUE )
	{
		//TODO: gestion erreur
		return false;
	}
 
	DCB				dcb;
	ZeroMemory(&dcb, sizeof(DCB));
	COMMTIMEOUTS	timeouts;
	dcb.DCBlength	= sizeof(DCB);
	dcb.ByteSize	= 8;
	dcb.Parity		= NOPARITY;
	dcb.StopBits	= ONESTOPBIT;
	dcb.BaudRate	= CBR_38400;
	dcb.fRtsControl = RTS_CONTROL_DISABLE;
	dcb.fDtrControl = DTR_CONTROL_DISABLE;
 
	if ( GetCommTimeouts( m_hCom, &timeouts ) == 0 )
	{
		//TODO: gestion erreur
		return false;
	}
 
	timeouts.ReadIntervalTimeout = MAXDWORD;
	if ( SetCommTimeouts( m_hCom, &timeouts) == 0 )
	{
		//TODO: gestion erreur
		return false;
	}
 
	if ( SetCommState( m_hCom, &dcb) == 0 )
	{
		//TODO: gestion erreur
		return false;
	}
 
	return true;
}
 
void SerialPortManager::FlushPort()
{
	DWORD	nChar	= 1;
	BYTE	cInBuf [8];
	while ( nChar >0 )
		ReadFile( m_hCom, cInBuf, 1, &nChar, NULL);
}
 
int SerialPortManager::Read( unsigned char * buffer, int buffLen )
{
	int	nbRetry = 5;
	int	nbCharRead = 0;
	int	countFailed	= 0;
	DWORD	nChar	= 0;
 
	while ( countFailed < reintentos )
	{
		ReadFile( m_hCom, &buffer[nbCharLeido], 1, &nChar, NULL );
		if ( nChar > 0 )
		{
			nbCharRead +=nChar;
		}
		else
		{
			countFailed++;
			Sleep( 100 );
		}
	}
 
	return nbCharRead;
}
 
void SerialPortManager::Write( const unsigned char * buffer, const int buffLen )
{	
 
	DWORD nChar = 0;
	if ( WriteFile( m_hCom, buffer, buffLen, &nChar, NULL) == 0 )
	{
		// TODO: gestion erreur
	}
}
 
void SerialPortManager::ClosePort()
{
	std::cout << "ClosePort" << std::endl;
	CloseHandle( m_hCom );
}

Hope it helps.

[yan]

Bonjour,

quelques conseils en vrac:

-> de fa�on g�n�rale, le mode asynchrone pour le port s�rie est d�conseill� car trop difficile � g�rer et le mode synchrone est suffisant dans l'immense majorit� des cas.

le mode asynchrone est plust�t conseill�...
Avec Qt �a se fait comme une lettre � la poste. �a � surtout l'avantage de ne pas bloquer l'application lors de la lecture du port.

[Tymk]

Merci, pour ces precisions.

J'ai regarde ta classe et elle est similaire a celle que je viens tout juste de terminer. Il y a quand meme deux differences que je ne comprends pas :

Quelle est l'utilitee du ZeroMemory dans le renseignement de la strucutre DCB ?

Quelle est l'utilite de la fonction FlushPort() ? Elle semble lire des octets tant qu'elle en recoit.

[Tymk]

le mode asynchrone est plust�t conseill�...
Avec Qt �a se fait comme une lettre � la poste. �a � surtout l'avantage de ne pas bloquer l'application lors de la lecture du port.

Pourquoi, le mode asynchrone serait plus indique ? Si je suis les conseils de r0d en faisant n essais de lecture le port se liberera forcement.

[yan]

Pourquoi, le mode asynchrone serait plus indique ? Si je suis les conseils de r0d en faisant n essais de lecture le port se liberera forcement.

la lecture sur le port est bloquante, c'est � dire que si il n'y as rien � lire, la lecture va bloquer l'ex�cution. Donc si tu utilise une thread, tous ton programme est bloqu�. Utiliser un thread qui fera la lecture permet de ne pas bloquer le reste. Que la thread se bloque, c'est pas grave puis qu'elle sert � ca.
Si tu as une IHM, c'est pas terrible d'avoir l'ihm qui ne repond plus.

De la m�me mani�re, si tu lit beaucoup de donn�e, ton application ne fera que �a et va laisser peu de ressource pour le reste=> m�me probl�me.

[Tymk]

Ok, mais je suis plutot de l'avis de r0d : rester simple si possible.

Je pense que je peux m'en sortir de la sorte :

Je sais exactement ce que je dois obtenir en lecture car c'est le PC qui interroge l'interface. L'interface ne fait que repondre. Donc, j'envoie mon message et je passe en lecture sur le peripherique pour recuperer la reponse.

Si l'interface repond plus vite que le temps necessaire au programme passe de l'ecriture en lecture (ce dont je doute), le driver bufferise les octets.

Ensuite, je lis les octets correspondant a l'en-tete de mon paquet. Je connais maintenant la taille exacte du paquet. Je recupere donc le nombre d'octets restants.

Pendant ce temps, le programme ne peut rien faire d'autre sans la reponse de l'interface. D'ou l'inutilite du threading.

Fonctionnement non-nominal :

Si le programme attend des octets que l'interface n'envoie pas, un timeout sort de la lecture et la requete est renvoyee.

Si le programme recupere moins d'octets que ce qu'a envoyee l'interface, le crc permet de detecter l'erreur.

[edit] Mon application n'interagit pas avec un utilisateur [/edit]

[yan]

Je sais exactement ce que je dois obtenir en lecture car c'est le PC qui interroge l'interface. L'interface ne fait que repondre. Donc, j'envoie mon message et je passe en lecture sur le peripherique pour recuperer la reponse.

Pendant ce temps, le programme ne peut rien faire d'autre sans la reponse de l'interface.

Si le programme attend des octets que l'interface n'envoie pas, un timeout sort de la lecture et la requete est renvoyee.

Et que pense tu qui va se pass� � ton interface pendant c'est periode(en gras)???
=>interface bloqu�, non r�pondante, qui deviens blanc ou autre jusqu'a la recuperation des ressources
Bien sur que tu peut te pass� d'une thread pour faire simple. Mais simple ne correspond pas toujours � performant et ce qu'il faut faire...
Apr�s ce n'est que mon avis
a toi de voire

[Tymk]

Pardon, je me suis mal exprime.

Je parlais d'interface pour signifier "validateur d'acces". C'est une interface electronique qui se situe a l'autre bout du cable et a laquelle je ne touche pas. Il ne s'agit pas d'interface graphique. Mon application est autonome.

[r0d]

Ooops oui pardon, je voulais dire l'inverse

de fa�on g�n�rale, le mode synchrone pour le port s�rie est d�conseill� car trop difficile � g�rer et le mode asynchrone est suffisant dans l'immense majorit� des cas.

pardon

Au sujet d'un thread ou non, effectivement tout d�pend de savoir si le "blocage" de ton appli est un probl�me ou non. Dans certains cas, il peut m�me �tre souhaitable.

Quelle est l'utilitee du ZeroMemory dans le renseignement de la strucutre DCB ?

Dans certains cas (en fait je crois presque tout le temps), �a ne fonctionnera tout simplement pas si tu ne le fais pas. Le standard c++ ne pr�cise pas comment doit �tre initialis�e une structure. Ce que je veux dire, c'est que lorsque d�clar une structure (lorsque tu en cr�� uns instance donc), les compilateurs la remplissent n'importe comment. Le ZeroMemory la rempli de 0 (z�ro).

Quelle est l'utilite de la fonction FlushPort() ? Elle semble lire des octets tant qu'elle en recoit.

C'est exactement �a. Cette fonction sert � vider le buffer d'entr�e du port serie. Elle est indispensable dans certains cas, mais pas toujours. Par exemple, en ce moment je travail sur une machine qui m'envoie une "preuve de vie": toute les 10 secondes, elle m'envoie un octet (0x00 dans mon cas pr�cis). Je suis donc oblig� de vider le buffer (flush) avant chaque envoi/r�ception de trame. Il y a aussi des machines qui envoie des parasytes, c'est � dire qu'ils envoient de temps en temps des octets "poubelle" sur le port. J'en avais rencontr� lorsque je bossait dans la RFID.

[Tymk]

Ok

Pour le mode asynchrone, il suffit de renseigner le flag ldOverlap ou il y a d'autres modifications a faire dans le code ?

Au passage, r0d, ta classe ouvre un port en mode synchrone, il me semble.

[r0d]

Pour le mode asynchrone, il suffit de renseigner le flag ldOverlap ou il y a d'autres modifications a faire dans le code ?

Je ne sais pas.

Au passage, r0d, ta classe ouvre un port en mode synchrone, il me semble.

Mhh, je ne sais plus. Il me semble effectivement qu'il y a deux fa�on d'utiliser le mot synchrone/asynchrone quand on parle du port serie. Mais je ne sais plus l�, vous m'avez perdu

[yan]

http://www.developpez.net/forums/sho...d.php?t=582572

[wiztricks]

J'aime bien un d�coupage en 3 couches:

application (7) -> session (4) -> liaison de donn�es (2)

Lorsqu'on va passer de RS232 � Ethernet, ce sera pour supporter plusieurs connexions.

1. Que peut-on faire c�t� "design" pour limiter les changements � la couche "liaison de donn�es"?
2. Et autoriser la gestion de plusieurs sessions � la fois?

Le fant�me threads ou pas traine toujours dans le d�cors ;-(
- W

[Spout]

La manipulation des paquets via basic_string<unsigned char> est-elle viable ?

Attention � �tre bien s�r que les donn�es qui transitent sur ta liaison RS232 sont sous forme ASCII et non binaire. En effet, en ASCII le '\0' = NULL = 0 terminera la cha�ne et ira tr�s bien avec ce container. Mais en binaire, ta trame pourra tr�s bien contenir un 0 qui fera tomber le reste de ta trame aux oubliettes.
Attention �galement aux trames UNICODE, car chaque caract�re ASCII imprimable chez nous sera pr�c�d� d'un 0 et n'ira donc pas avec ton container.

Sinon, j'ai appris par exp�rience que l'utilisation d'un nom de flux de type "COMX" pour le CreateFile d'une liaison s�rie est limit�e jusqu'au COM9. Si tu veux utiliser un port COM sup�rieur (possible jusqu'� 255 il me semble), il faut utiliser la notation compl�te du p�riph�rique s�rie:

Code :

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

1
2
3
4
5
6
7
8
wsprintf( sz, "\\\\.\\COM%d", portnumber);   
m_hCom = CreateFile( sz,
        GENERIC_READ | GENERIC_WRITE,
        0,
        NULL,
        OPEN_EXISTING,
        FILE_FLAG_OVERLAPPED,
        NULL );

Mais soyons honn�tes, tout le monde n'a pas 36 ports COM

Enfin, pour ce qui est du thread ou non, tu connais d�j� mon avis...

[3DArchi]

Quelques conseils a adapt� ensuite selon tes envies et besoins:
-> Si ton syst�me est asym�trique (un �metteur et un r�cepteur), je sp�cialiserais les classes RS323 et PROTOCOL en deux: une pour l'�mission et une pour la r�ception,
-> Si tu penses ensuite aller sur du IP, tes sockets pourront se situer � ce niveau (PROTOCOL pour TCP, RS232 pour UDP),
-> Personnellement, je pr�f�re le mode asynchrone. Cela permet de garder une certaine dynamique � ton programme: ton syst�me peut encore r�agir � l'environnement (IHM, signaux, etc...),
-> Je pr�f�re d�couper les syst�mes avec des flux r�seaux en plusieurs thread: un pour la communication, un pour le traitement principal et en poussant le vice, un sp�cifiquement � l'IHM. Ca semble plus compliqu� mais au final c'est plus souple, notamment pour la gestion des erreurs.
Tout ceci est ensuite � adapter aux sp�cificit�s de ton syst�me et au temps dont tu disposes pour le d�velopper.
Cordialement.

[Tymk]

Attention � �tre bien s�r que les donn�es qui transitent sur ta liaison RS232 sont sous forme ASCII et non binaire. En effet, en ASCII le '\0' = NULL = 0 terminera la cha�ne et ira tr�s bien avec ce container. Mais en binaire, ta trame pourra tr�s bien contenir un 0 qui fera tomber le reste de ta trame aux oubliettes.

Il me semblait que la classe string ne contenait pas de caractere de fin de chaine. En tout cas, j'arrive a envoyer/recevoir des tames en affectant a certains unsigned char la valeur 0x00.

Enfin, pour ce qui est du thread ou non, tu connais d�j� mon avis...

Oui, je sais que ce sujet a deja ete discute. Je me suis permis de reposer la question pour collecter plus d'avis.

[Spout]

Il me semblait que la classe string ne contenait pas de caractere de fin de chaine.

Si l'on parle bien de la classe string de la STL, un 0 est plac� � la fin de la cha�ne du buffer interne. Tu peux le v�rifier avec le code suivant:

Code :

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

1
2
3
4
5
6
7
std::string sEssai;
sEssai.push_back('a');
sEssai.push_back('b');
sEssai.push_back(0);
sEssai.push_back('c');
sEssai.push_back('d');
sEssai.push_back('e');

En debug, si tu regardes le buffer du string sEssai, tu verras qu'il y a un 0 � la fin des caract�res de la cha�ne.

En tout cas, j'arrive a envoyer/recevoir des tames en affectant a certains unsigned char la valeur 0x00.

OK je me suis mal exprim�. Avec l'exemple que je t'ai donn�, tu verras qu'effectivement le buffer continue de se remplir apr�s l'ajout du 0. Mais si tu utilises par exemple le code suivant:

Code :

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

1
2
char sBuffer[10];
sprintf(sBuffer, sEssai.c_str());

tu verras que le .c_str() renvoie une cha�ne de caract�re qui s'arr�te au 0, donc "ab".
L'important es d'�tre conscient de cette subtilit�

[Tymk]

Le point que tu souleves est tres important puisque les fonctions WriteFile et ReadFile demande des pointeurs sur des types constants. (Donc, necessite la conversion vers des chaines C).

Mais, j'ai contourne le probleme en parcourant mon basic_string<unsigned char> et en envoyant/recevant les octets un par un.

[wiztricks]

Le point que tu souleves est tres important puisque les fonctions WriteFile et ReadFile demande des pointeurs sur des types constants. (Donc, necessite la conversion vers des chaines C).

Mais, j'ai contourne le probleme en parcourant mon basic_string<unsigned char> et en envoyant/recevant les octets un par un.

ne serait-il pas plus sage de d�finir une "trame" comme:

Code :

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

1
2
unsigned char length; // la longueur
unsigned char data[MAX_TRAME]; // le contenu.

plut�t que de canibaliser un type qui n'est qu'un tableau de caract�re dans lequel 0 � un sens assez particulier?
-W