Commentaires de billou_13 sur tout CodeS-SourceS

22 commentaire(s) de billou_13 sur des sources sur tout CodeS-SourceS

Le : 19/06/2008 15:46:13
Source : BASE POUR SERVEUR/CLIENT TCP/IP AVEC NETWORKSTREAM

Il semblerait que ce soit la raison : http://msdn.microsoft.com/fr-fr/library/system.net.ipendpoint(VS.80).aspx (This page is specific to
Microsoft Visual Studio 2005/.NET Framework 2.0)

Pour le framework 1.1, je ne vois pas et je n'ai pas Visual Studio 2003 sur mon poste.

Billou_13

Le : 19/06/2008 12:28:28
Source : BASE POUR SERVEUR/CLIENT TCP/IP AVEC NETWORKSTREAM

Je comprends pas, chez moi, ca marche très bien.
Je ne vois pas ce qui clôche. Désolé

Billou_13

Le : 19/06/2008 11:33:29
Source : BASE POUR SERVEUR/CLIENT TCP/IP AVEC NETWORKSTREAM

Dans ce cas, tu peux faire un fichier d'association "Adresse IP"-"Serveur". Un fichier texte peut faire l'affaire (ou xml à la limite: en utilisant les fichiers Settings, ca peut être classe ^^). Ainsi, ton appli serveur pourra identifier les connections.

Pour connaitre l'adresse IP de la personne qui se connecte, j'ai trop eu le temps de voir mais je pense que j'ai une piste:
- Après la ligne:
TCP_Client = TCP_Serveur.AcceptTcpClient();
- Ajoute la ligne:
IPAddress address = ((IPEndPoint)TCP_Client.Client.RemoteEndPoint).Address;
Tu auras alors accès à l'adresse IP dans l'objet "address".

Voila,

Bonne journée,

Billou

Le : 19/06/2008 09:14:37
Source : BASE POUR SERVEUR/CLIENT TCP/IP AVEC NETWORKSTREAM

Bonjour,

Tout d'abord, merci pour le (et j'en profite pour dire merci à tous les commentaires) commentaire.

Pour la reconnection d'un client, tu peux très bien conserver le lien adresse IP - Login en utilisant la classe Dictionnary<TKey, TValue>. Ainsi, tu pourras lui ré-attribuer le login à sa reconnection.
Cependant, il y a plusieurs hics (ce qui explique pourquoi la plupart des gens ne font pas comme ça ^^):
  1) Tu pouvais avant connecter un même poste plusieurs fois sur le chat sans aucun souci. Aujourd'hui, ils auront le même login: pas cool !
  2) Le dictionnary grandit à l'infini (il faut donc un time-out) pour le purger de temps en temps. Et là, ca complique les choses.
  3) Quand tu redémarre ton serveur, tu perds toutes les infos.

C'est pour cela que :
  - Soit tu demandes le login souhaité à la connection (et tu vérifies qu'il n'existe pas déjà).
  - Soit tu créé un système de "login/mot de passe" que tu garderas côté serveur (dans une base de données, un fichier, ...).

Bonne journée,

Billou_13

Le : 09/05/2008 09:51:33
Source : WEB SKIN : CRÉEZ UNE INTERFACE ASPNET POUR VOTRE CLIENT LOURD DOTNET SANS IIS. HÉBERGEMENT INTERNE DE WEBAPP.

Bonjour,

Le débat est fort intéressant et pourrait durer un bon moment: peut-on mélanger client lourd/client léger ?
Pour ma part, je pense que non pour les même raisons que Sebmafate. Un client lourd a ses avantages fortement appréciables. Néanmoins, il est vrai que les entreprises (du moins, basé sur mon expérience) ont tendance à faire route vers des clients légers (comme disait Seb: plus appréciable pour leur côté maintenance).
Mais je ne pense vraiment pas que ce soit le côté graphique et interface qui rebutent les gens à utiliser les logiciels client lourd.

Enfin tout ça pour dire que l'intérêt de ce code n'est pas moindre. Il m'intéresse beaucoup et, faute à moi de ne pas télécharger tous les codes du site, il fera partie de la rare liste de code que j'aurais téléchargé sur code source afin de le dépouiller. Il m'apprendra certainement beaucoup de choses dans ma courte expérience du .Net.
Et pour cela (ne pas avoir laisser dormir le code sur ton ordi sans jamais le poster), je t'en remercie GodVicien

Bonne journée,

Billou_13

PS: Et n'oubliez pas, avant de s'occuper de supprimer les clients lourds, faudrait surement penser à s'occuper de la communauté JAVA d'abord ^^

Le : 02/05/2008 13:30:25
Source : UPLOAD FILE

C'est bien ce que je venais de dire ^^: j'avais pas chercher car après une minute, voici un lien qui tombe:
http://humann.developpez.com/httphandler/

Bonne journée,

Billou_13

Le : 02/05/2008 13:28:13
Source : UPLOAD FILE

Bonjour,

Merci pour la discussion, la démonstration de la faille est plus qu'intéressante.
Cependant, ne connaissant pas les handlers, auriez-vous des liens ou autres qui seraient susceptibles de m'expliquer la mise en place et le fonctionnement ?
J'avoue: je n'ai pas encore chercher sur le net et sur le forum, je viens juste de lire la discussion et je me dis qu'il vaut mieux demander au cas où vous auriez cela sous le coude.

Je vous remercie par avance,

Très bonne fin de journée,

Billou_13

Le : 07/02/2008 10:37:04
Source : LES TRANSACTIONS

Bonjour à tous,

Mon commentaire est un peu tardif mais je viens de me mettre aux transactions et je suis donc tombée sur cette source. Effectivement, elle ne m'a pas beaucoup aider.
Merci à AnMullerDeKush pour le complément d'informations.

En continuant sur une recherche internet, je suis tombé sur une explication très claire et instructive pour les transactions. J'en fais donc profiter tout le monde :
http://baptiste-wicht.developpez.com/tutoriel/ms-sql/securiser/

Cordialement,

Billou_13

Le : 22/01/2008 19:29:34
Source : ENVOI D'EMAILS AVEC LES CLASSES .NET - MAIL MESSAGE

J'avais oublié la note avec tout ça ^^

Le : 22/01/2008 19:11:00
Source : ENVOI D'EMAILS AVEC LES CLASSES .NET - MAIL MESSAGE

Je vais répondre à ta question oximoron.

Tu as tout à fait raison sur le fait que ce n'est pas bon de lancer des exceptions à tout bout de champs. C'est pourquoi il est très important de se poser la question : envoyer une exception ou renvoyer un code erreur.

Je vais donc parler personnellement car ce choix est à la décision de chacun.
Je pense qu'un code erreur ne peut être renvoyé que si le déroulement a été normal et surtout, si l'erreur était à prévoir pour le besoin utilisateur.
Exemple: on te demande de faire un logiciel qui va scanner un fichier formaté de telle facon tout en vérifiant les erreurs possibles (erreur de formatage d'un entier,...). Dans ce cas, il vaut mieux préférer le recours à un code erreur (int.TryParse(...)) plutot que de faire des int.Parse et catcher les erreurs.

Seulement, dans le cas de cette méthode Send(...), c'est bien plus qu'une simple erreur, c'est une erreur qui ne doit jamais arriver. C'est au développeur qui appelle la méthode de vérifier au préalable.
foreach(string curAdr in listeAdresses)
{
if(!string.IsNullOrEmpty(curAdr))
Send(...);
}

Mais aussi, une raison de plus, imagines que quelqu'un utilise cette classe mais qu'il s'en fout du code de retour de la fonction. Il va croire que tout va bien alors que non. En lui envoyant une exception, tu lui indiques une erreur dans son programme: le destinataire ne doit pas être vide.

Voila ce que je pense mais c'est au désir de chacun ^^

Et pour finir, je voudrais faire une proposition qui pourrait combler tout le monde. Pourquoi ne pas enlever complétement ce test et laisser le framework faire ce qu'il veut de cet argument (à voir: http://msdn2.microsoft.com/fr-fr/library/swas0fwc(VS.80).aspx). Car après tout, ce n'est peut être pas à la fonction test de faire ce test mais plutôt à la fonction smtp.Send(mail);
Comme ça, plus de problème ^^

Bonne soirée à tous,