begin process at 2008 09 05 14:27:09
1 237 266 membres
220 nouveaux aujourd'hui
14 313 membres club

Vous ne trouvez pas de réponse à votre problème ? Alors posez la question dans le forum.
Souvenez-vous qu'il n'y a jamais de question bête, mais rester dans l'ignorance parce que l'on n'ose pas poser une question, ça c'est une erreur !

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,



[ Page 1 Page 2 ]

Pub



Appels d'offres

Recherche developpeur ...
Budget : 700€
SITE MARCHAND LOCATION...
Budget : 3 000€
SITE MARCHAND POUR HOTEL
Budget : 4 000€

CalendriCode

Septembre 2008
LMMJVSD
1234567
891011121314
15161718192021
22232425262728
2930     

VS Express FR Gratuit !

VS Express en français et 100% gratuit !

Boutique

Boutique de goodies CodeS-SourceS