Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes
pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en
dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre
avis. Si vous désirez poser une question, merci d'utiliser Derniers journaux de Regit :
- [02/05@15:47] NuFW 1.0.3 est sortie, gnutls 1.0.25 et 1.2.3 aussi
- [15/02@23:37] NuFW 1.0-rc1 est disponible
- [05/12@20:57] NuFW 0.6, objectifs fonctionnels atteints
À signaler également, de nouvelles fonctionnalités comme une option de nufw permettant d’améliorer la vérification du certificat de nuauth et quelques corrections de bogues.
Cette version devrait clore les évolutions fonctionnelles de la branche 1.0. Le travail sur la branche de développement 1.1.x devrait donc bientôt commencer.
Le programme des évolutions n'est pas encore complètement défini et toutes les suggestions sont donc les bienvenues. N'hésitez pas à faire des commentaires !
> Lire le journal (6 commentaires, moyenne: 1,8).
...
Au passage il se situait ou les pb d'endianess ?
J'ai du mal a voir ou ca peut intervenir dans un parefeu.
-
[^]Re: ...
Posté par Eric Leblond (page perso, ) le 26/07/2005 à 11:28. (lien). Évalué à 2.L'architecture de NuFW est en mode client/serveur :
http://www.nufw.org/article.php3?id_article=3(...)
Les problèmes étaient au niveau des échanges entre les différents composants car toutes les données de type adresse IP, ports, longueur de paquets sont envoyées de manière binaire.
Conçu et testé sur machines little endian, le protocole ne se comporte pas de manière idéale lors d'un changement d'endianness. Il a donc été nécessaire de faire les conversions nécessaires au niveau du parsage des informations reçues et au niveau des envoi de données.-
[^]Re: ...
Posté par Matthieu C () le 26/07/2005 à 13:59. (lien). Évalué à 3.ou m'enfin y a les fonctions htons et equivalent qui permet de gerer les infos binnaires sur un réseau....
Et si l'appli avait bien ete concu elle aurait du les utiliser.-
[^]Re: ...
Posté par Eric Leblond (page perso, ) le 26/07/2005 à 14:11. (lien). Évalué à 1.Mea culpa, oui c'est ce qui est utilisé maintenant.
> Et si l'appli avait bien ete concu elle aurait du les utiliser.
On n'a pas tous fait l'ENSIMAG option système et réseau ;-) certains sont autodidactes d'où certaines approximations lors de la conception du protocole d'échange ...-
[^]Re: ...
Posté par Sylvain Briole (page perso, ) le 26/07/2005 à 14:17. (lien). Évalué à 2.Juste une petite curiosité (je n'ai pas fait ENSIMAG option système et réseau ;-)) : comment faisiez-vous les échanges alors? Dans tous les exemples que je trouve couramment sur le net concernant la conception d'applications réseau en UDP & TCP/IP, c'est htons qui est conseillé....
Je ne savais même pas qu'on pouvait utiliser aut' chose.... C'est dire!-
[^]Re: ...
Posté par Eric Leblond (page perso, ) le 26/07/2005 à 15:04. (lien). Évalué à 1.En fait c'est plus subtil que ça. Lors de la définition des échanges bianires du protocole il est nécessaire de définir une endianess des envois de données binaires. C'est à tort, que l'encodage little endian a été choisi lors des développements initiaux (effectué sur plateforme x86, donc choix implicite). Hors les fonctions de la famille htons sont égales à l'identité sur architecture big endian. On ne peut donc pas effectuer de conversion par leur aide.
Morale de l'histoire : mettre les champs en big endian avant d'envoyer sur le réseau pour ne pas avoir de problèmes avec les architectures big endian lorsque l'on définit un protocole.
Je regrette rarement d'être autodidacte en informatique, là c'est le cas ;-)
-
-
-
-
Cette page a été générée par Templeet en 0.058s (dont 0.0051 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.