NETACCESS 2.0 RC2 : LIBRAIRIE POUR APPLICATION CLIENTS/SERVEUR
cs_wizad
Messages postés
355
Date d'inscription
samedi 30 octobre 2004
Statut
Membre
Dernière intervention
14 avril 2009
-
13 sept. 2007 à 18:19
cs_wizad Messages postés 355 Date d'inscription samedi 30 octobre 2004 Statut Membre Dernière intervention 14 avril 2009 - 4 mars 2008 à 00:58
cs_wizad Messages postés 355 Date d'inscription samedi 30 octobre 2004 Statut Membre Dernière intervention 14 avril 2009 - 4 mars 2008 à 00:58
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/44032-netaccess-2-0-rc2-librairie-pour-application-clients-serveur
https://codes-sources.commentcamarche.net/source/44032-netaccess-2-0-rc2-librairie-pour-application-clients-serveur
4 mars 2008 à 00:58
http://www.csharpfr.com/codes/DEMO-NETACCESS-NETMESSENGER_45942.aspx
4 mars 2008 à 00:39
Bon test.
Je publie dans la foulé la première démo
3 mars 2008 à 20:40
3 mars 2008 à 19:59
Je te contact par MP pour en savoir plus sur les modifications que tu as faites (éventuellement certaine pourrait être intégrable)
3 mars 2008 à 19:55
3 mars 2008 à 08:18
Sinon juste pour vous dire que le stockage des client est passé de HashTable en Dictionary. De plus comme vous pouvez le devinez sur le dictionary, les id client sont repassé en int (afin d'éviter des cast en string inutile).
Pour la suite du changelog je vous laisse patienter jusque cet après midi.
3 mars 2008 à 07:09
Il faut remplacer le foreach (Client loClient in m_clients)
par foreach (Client loClient in m_clients.Values)
@BAFM:oui on peut l'optimiser, moi j'ai fait cette fonction car dans mon cas ca marche bien dans un petit reseau local avec une dizaine de poste configuré en dhcp. Sinon au pire il faut passer l'id dans chaque envoi au serveur... mais attendons l'exemple ;
2 mars 2008 à 17:16
Je rajouterais qu'il serait plus judicieux de transformer le paramètre asIp en IPAddress au lieu de faire une comparaison de chaîne. Ca permet de gagner du temps sur la comparaison. De plus, il est possible de mettre en place un dictionnaire pour effectuer la recherche plus rapidement.
2 mars 2008 à 16:39
Concernant la licence ce sera vraisemblablement du LGPL.
Pour l'exemple je suis entrain de finaliser celui qui sera fournit avec le SDK (un classic chat).
Pour les try/catch j'en est corrigé et ce sera mis dans la version finale.
Concernant ta suggestion je vais voir à l'intégrer pour la version finale (je n'avais pas pensé à cette possibilité).
1 mars 2008 à 23:16
protected string Ip2IdClient(string asIp)
{
foreach (Client loClient in m_clients)
if(loClient.EndPoint.Address.ToString() == asIp)
return loClient.Id;
return asIp;
}
29 févr. 2008 à 18:41
24 janv. 2008 à 21:48
Pour les autres un démo devrait rapidement être disponible (je vais essayer de faire ça pour se week end).
Je précise aussi que j'ai déjà répertorié quelques erreurs et que ceux-ci sont corrigé. J'uploaderais la correction demain.
24 janv. 2008 à 21:37
Car j'essaie de la mettre en route mais sincèrement j'y arrive pas ;)
Tu aurais une appli exemple ? Un sample .. ?
Merci beaucoup en tout cas !
15 janv. 2008 à 17:51
La clef privé du serveur est codé en "dur" (par l'utilisateur de la lib) dans celui-ci. La clef public du serveur est codé en "dur" (par l'utilisateur de la lib) dans le client.
Au moment de la connexion, le client crée un couple de clef aléatoirement. Il envoi sa clef public au serveur (en prenant soit de crypter le message avec la clef publique du serveur).
Pour les échange, un clef privé est généré, on crypte le contenu avec (Rijndael) et on la transmet de façon crypte (RSA).
Concernant ta suggestion d'utilisation de certificat ça peut être une bonne idée mais faut que je documente la dessus.
NB : pour rijndael il s'agit du standart d'implémentation d'AES (http://fr.wikipedia.org/wiki/Rijndael)
PS : pas de soucis pour le canal IRC je tenais juste à expliquer ma démarche ;)
15 janv. 2008 à 17:42
Pour pousser un peu sur l'histoire de man in the middle, tu peux alors faire en sorte de pouvoir utiliser des certificats, la validation des certificats par l'utilisateur, digest... Parce qu'il faut bien à un moment échanger les clés.
Pour éviter ces attaques, il est possible d'utiliser Diffie-Hellman, de s'envoyer des nonces et de signer les pacquets reçus afin de comparaison, en utilisant des Nonce et certaines autres parties du message.
Afin, il y a plein de manière d'éviter cette attaque tout en pouvant échanger des clés secrètement et de manière sécurisée. Le man in the middle n'étant pas au départ censé connaître le protocol.
Bonne continuation.
NB: La seul évocation de Rijndael n'indique pas l'utilisation d'AES, c'est le 'R' de RSA aussi je crois.
PS: Et le canal irc, ca n'a pas beaucoup d'impact, il y a tellement de monde dessus...
15 janv. 2008 à 17:20
J'était au départ partit sur la solution que vous proposez mais l'avais écarté pour un soucis de "sécurité" (qui en fait n'est que partiellement résolu avec le protocole que j'utilise).
Je vais donc refaire quelque recherche (et test de performance) à ce sujet.
Néammoins pour la partie performance, l'utilisation du crypte à "la demande" (uniquement pour la transmission des données sensible) permet d'en limiter l'impact.
15 janv. 2008 à 17:12
Si vous aviez pris le temps de consultez sérieusement la source vous auriez pu noter le protocole de cryptage. Celui-çi utilise le rsa en combinaison de l'AES (implémentation Rijndael) afin de palier au problème de lenteur.
Il s'agit d'ailleur d'un protocole fortement inspiré de l'implémentation même de SSL.
Concernant l'utilisation de SslStream plusieurs points font que je ne l'ai pas utiliser :
-> Volonté de maitrise du code (utilisation direct des sockets)
-> Intégration au travers de l'architecture existante
-> echange automatique des clefs publiques : celà peut paraître surprenant mais l'attribution "en dur" de la clef public du serveur et le protocole interne que j'utilise mais permettre de contrer une attaque de type "Man in the Middle".
Enfin pour répondre à votre remarque sur le channel programmation, mon but n'était pas de faire de la pub pour de la pub. Mais de faire connaitre cette lib pour rendre service (vu le nombre de message sur les notions clients/serveur qui peuplent le forum)
Cordialement, en espérant avoir répondu pleinement à vos question
PS : bien entendu je reste ouvert à tout débat constructif sur le sujet et le ton peut être un peu sec que j'emploi est uniquement du à ma volonté de précision. ;)
15 janv. 2008 à 16:57
Il aurait été plus intéressant d'utiliser le SslStream afin de crypter le flux. Les apports sont les suivants : échange automatique de clés publiques, configuration du type de cryptage désiré et meilleurs performances. (et aussi possibilité de faire un client pour un serveur déjà existant en crypté en SSL)
Le cryptage RSA est bien, mais il n'est pas fait pour crypter sur la durée, il nécessite de la charge et les pacquets font une taille fixe par blocks. L'utilisation après échange utilisant RSA d'une clé privé pour un algorithme symétrique qui sont généralements plus rapides (AES) reduit la charge et garde le niveau de protection.
Cordialement.
15 janv. 2008 à 13:59
Je viens de publier la nouvelle version de NetAccess (la béta 2) qui implémente désormais toutes les fonctionnalités prévu pour la v2.
Pour les nouveautées principale c'est en dessous :
-> Log avec différent niveau de rapport (les log sont désormais basé sur la librairie externe log4net disponible ici : http://logging.apache.org/log4net/)
-> Cryptage des transactions à la demande utilisant du RSA combiné avec Rijndael
-> Meilleur gestion des clients (expulsion avec message,...)
-> Possibilité d'indiquer un message envoyé au client automatique lors de l'arrêt du serveur.
-> Réécriture du système d'envoi/reception des messages pour une montée en charge bien meilleur (correction des mauvaises transmissions lors de la transmission de beaucoup de paquet en peu de temps | prise en charge des données dépassant la taille du buffer)
20 déc. 2007 à 21:04
J'ai résolu le problème.
Il était du à un process qui ne rendait pas la main.
Celà dit il est possible de se passer de nested. le code qui va suivre est thread Safe.
#region Singleton
static Log instance = new Log();
// Singleton Manager
//static Log instance = new Log();
static Log()
{
}
Log()
{
}
public static Log Instance
{
get
{
//return Nested.instance;
return instance;
}
}
#endregion
20 déc. 2007 à 13:01
voici le code en entier, les évènements n'arrives n'atteignent pas la classe une fois qu'on lance application.run(new fom1())
using System;
using System.Collections.Generic;
using System.Text;
namespace BeanGUI
{
public class Form_Server : System.Windows.Forms.Form
{
#region compiler added
private System.Windows.Forms.RichTextBox RichTxtBx_Log;
private void InitializeComponent()
{
this.RichTxtBx_Log = new System.Windows.Forms.RichTextBox();
this.SuspendLayout();
//
// RichTxtBx_Log
//
this.RichTxtBx_Log.Location = new System.Drawing.Point(45, 83);
this.RichTxtBx_Log.Name = "RichTxtBx_Log";
this.RichTxtBx_Log.Size = new System.Drawing.Size(273, 177);
this.RichTxtBx_Log.TabIndex = 0;
this.RichTxtBx_Log.Text = "";
//
// Form_Server
//
this.ClientSize = new System.Drawing.Size(368, 288);
this.Controls.Add(this.RichTxtBx_Log);
this.Name = "Form_Server";
this.ResumeLayout(false);
}
#endregion
public Form_Server()
{
InitializeComponent();
this.Subscribe();
}
#region safe write hadlers
public void Subscribe()
{
BeanLog.Log.Instance.LogAdded += new EventHandler(OnNewLog);
}
public void UnSubscribe()
{
BeanLog.Log.Instance.LogAdded -= new EventHandler(OnNewLog);
}
private void OnNewLog(object sender, BeanLog.Log.LogAddedEventArgs e)
{
String message = e.text + "\r\n";
InvokeAppendLog(message);
}
private void InvokeAppendLog(string message)
{
this.Invoke(new AppendLogHandler(AppendLog), new object[] { message });
}
private delegate void AppendLogHandler(string message);
private void AppendLog(string message)
{
this.RichTxtBx_Log.AppendText(message);
}
#endregion
}
}
20 déc. 2007 à 11:20
Merci beaucoup pour le feedback. Je l'ai implémenté et le résultat est le meme. Le code marche parfaitement bien une fois que la fenetre est fermée (le thread form continue mais les widjets associés sont détruits).Je vais implémenter le code dans un usercontrol et voir ce que ça donne.
cdt.
20 déc. 2007 à 08:27
Concernant le thread-safe voici généralement les 3 élément que j'utilise :
private void InvokeAppendLog(string message)
{
this.Invoke(new AppendLogHandler(AppendLog), new object[] { message });
}
private delegate void AppendLogHandler(string message);
private void AppendLog(string message)
{
this.textbox1.append(message);
}
Après il suffit d'appeler this.InvokeAppendLog("mon log");
20 déc. 2007 à 03:25
Je pense que certains vont etre confrontés au meme problème que je rencontre. Je cherhe à afficher les message de log dans un richTexbox. Les Form ne sont pas thread safe et il faut donc faire la manip suivante:
1) déclarer les délégates
internal delegate void UpdateDelegateHandler(String message);
private UpdateDelegateHandler UpdateDelegate
2) s'aboner à l'évènement log puis déclarer la methode à executer
private void init()
{
UpdateDelegate = new UpdateDelegateHandler(safeWrite);
Log.Instance.LogAdded += new EventHandler(OnNewLog);
}
private void OnNewLog(object sender, BeanLog.Log.LogAddedEventArgs e)
{
String message = e.text + "\r\n";
this.safeWrite(message);
}
3) déclarer uneméthode d'écriture sécurisée
private void safewrite(String Message)
{
this.texbox1.append(message);
}
4) j'instancie la Form de la manière suivante
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Form MainFrom = new FormMain();
Application.DoEvents();
Application.Run(MainFrom);
Problème: la fenetre se lance et je vois gace au débogeur que les évènements n'alimentent pas l'écran. En revanche lorsque je ferme la fenetre (bouton fermer) les évenments commencent à affluer.
Est-ce que quelqu'un connaitrait des remèdes? faut il instancier Form de manière spécifique? Faut il trainter les évènements autrement?
18 déc. 2007 à 10:51
En fait il y a un exemple dans la classe client manager.
Exemple que je n'avais pas vu. Le compilateur m'envoyait une erreur sur le typage (alors que j'avais bien indiqué
NetAcess.Log.Instance.LogAdded += new EventHandler<LogAddedEventArgs>(WriteLogEntry);).
il fallait rajouter Log.LogAddedEventArgs
Encore merci
18 déc. 2007 à 07:33
Lof.Instance.LogAdded += ...
18 déc. 2007 à 02:20
Je n'ai pas pu trouver d'exemple d'implémentation conernant le traitement des logs. En effet comment fait on afin de souscrire une classe au Log afin de récuperer le flux et le traiter le évenement
public event EventHandler<LogAddedEventArgs> LogAdded;
Bien cordialement.
16 déc. 2007 à 15:18
Concernant l'évolution, rendez-vous début janvier (au retour des vacances) pour le code sources de la béta 2 (qui devrait cette fois intégrer l'intégralité des nouveauté prévu de la v2 v).
Pour vous donnez quelques exemples d'applications j'ai pu tester la béta 2 (en cours de dev) sur des applis varié : transmission de webcam, transfert de fichier,... . Une des applications que je n'ai par contre pas pu tester est la transmssion de voix : je n'ai à l'heure actuellement pas trouvé de librairie de capture audio.
Pour le moment je mise sur un sortie finale de la v2 pour le 14 février (date de mon anniversaire pour la petite histoire ;) ).
Bon réseau à tous!
16 déc. 2007 à 11:59
Je re upload le zip sans la clef ce soir. (ou dans la journée si j'ai un peu de temps).
16 déc. 2007 à 11:46
Ne connaisant pas le mot de passe, il est impossible de lancer le projet.
cdt
26 oct. 2007 à 00:01
25 oct. 2007 à 20:53
20 sept. 2007 à 07:59
Sinon pour toute les idées et suggestions de nouvelles fonctionnalitées pour la version prochaine je reste bien entendu à l'écoute.
20 sept. 2007 à 00:44
Merci pour le travail et bon courage pour la finalisation.
17 sept. 2007 à 11:12
17 sept. 2007 à 09:32
17 sept. 2007 à 09:08
Merci pour ton beau boulot.
Je viens juste de télécharger celui-ci, mais j'en profite quand même pour te dire que la première mouture promettais et que je suis sur que celle ci me plaira également.
13 sept. 2007 à 18:19