Slt!
Bon, je commence à faire un petit chat en UDP en cours
et j'aimerais avoir des précisions sur le fonctionnement, les différents points à traiter, et voir s'il qq'un n'aurait pas un exemple à me montrer.
Ce sera d'abord en mode texte (on verra plus tard pour le graphisme..) et on pourra bien entendu envoyer des messages privés. Par contre, il n'y a pas de serveur.

was here

 
mmm ...dire a ton prof que c con de faire ca en UDP ?

 
 
Ben je sais pas trop, je commence seulement dans tout ça.
Si tu peux me donner les avantages/inconvénients de tout ça.
Merci.

commence à réfléchir un minimum avant de chercher les avantages/inconvénients. UDP n'est pas un acronyme que tu balançes comme ça. Tu dois qd meme connaitre un minimum non?

I was here

Oui, je connais un minimun, mais je ne vois pas encore
trop les différences notables que ça pourrait faire sur un chat.
Je sais que l'UDP en un mode non connecté (contrairement au TCP)... mais j'aimerais savoir par rapport au chat.
 
Merci

c'est surtout que l'acheminement des trames et leur ordre n'est pas garanti, donc tu peux très bien perdre des messages ...
 
et puis sans serveur ca veut dire que tu fais du multicast => uniquement en LAN et c'est pas performant ...

 
bah meme pas forcément en multicast, simplement en p2p, mais a mon avis c ptet deja un poil complexe

ben c'est super con de faire de l'udp en java !  
Suffit d'utiliser les java.net.DatagramMachin : http://www.cs.rpi.edu/courses/fall [...] avaudp.pdf
 
bien sur, ca se complique si tu veux gerer pas les erreurs réseaux
 

 
il n'a jamais été question de dire si c'était compliqué ou pas. La seule chose qu'on dit c'est que c'est pas du tout adapté. Avant de donner une solution technique faudrait peut etre voir si c'est viable  

 
quoi par rapport au chat? C'est qu'une bête application réseau comme une autre ... Faut voir si tu peux te permettre de recevoir tes paquests sans séquence et peut etre en perdre l'un ou l'autre ... Réfléchis et tu verras que ca n'a aucun sens

 
ah j'avais pas vu ce post là désolé
 
bin même du multicast hein benou. T'en connais bcp toi des environnemens qui le supportent correctement ... Un LAN ouais mais même ...

 
Un chat uniquement en LAN, ça va être bien comme truc !

 
bin ca peut avoir son intéret mais là n'est pas la question de toutes façons

ben moi j'avais fait ca en TP ... je pense pas que ce soit une grosse appli son machin !

 
non d'accord mais faire un chat en UDP ça n'a aucun sens. Si ce n'est éventuellement de montrer qu'UDP n'est pas fait pour ca. A part ca je ne vois pas désolé ...

Ouai, c'est bien de l'UDP et pour un LAN uniquement..
En plus, normalement ça doit prendre environ 3 TP de 3h
donc ça ne doit pas être vraiment ENORME !!
 
Sinon, pour le net, c'est possible de  faire un chat en Java,
ou est-ce qu'il vaut mieux faire ça en ASP ou PHP (je ne connais pas ces langages).

was here pour la deuxième question

IWH aussi

évidement que c'est possible.  
pour la deuxième partie, tu mélanges tout !

On parle de chat, on parle de java...Ca tombe bien, j'ai une question qui me turlupine (oui oui).
Dans un thread (n°1) qui receptionne les messages, on a priori un readln() qui attend des données d'un flux...
Question: quand la communication est arrétée par un autre thread (n°2), comment on arrète le thread n°1 sachant qu'il est probablement "en attente" de l'exécution de l'io? (à part le stop() )
 
je suis clair là? C'est marrant mais je me suis jamais posé des questions de concurrency sur des threads qui attendaient des entrées/sorties d'un ordi distant.

 
tu peux mettre un timeout sur toutes socket que tu crées. Donc si ta socket part en timeout une exception est levée. Est ce que ca répond à ta question?

 
Oui pourquoi pas...
 
Cela dit, dans la boucle du thread (et dans ma conception du truc), il devrait y avoir une variable qui dit si la communication tiens toujours ou pas...
En fait, le thread passe le test du while (communication) et lance le client.in.readln()...Là il repasse la main à un autre thread.
Quand il revient (s'il revient), il attend toujours un retour de readln alors que la communication est déjà arrété...D'où problème.
 
Remarque je pourrais avoir une boucle infinie et une exception levée quand "communication" passe à false. Et pof je fais un stop() sur le thread.
Hum...

bin si l'un ou l'autre ferme la connexion tu vas te manger une exception qd tu voudrais lire dessus ...

 
Je suis pas sur que naturellement il envoie une exception... A vérifier.

 
 
c'est dépendant de l'OS. Mais si tu fais un close() dessus normaleent tu dois te prendre une IOException ...

 
Ok je vais tester ca ce soir avec un petit chat client/server histoire de dérouiller mes notions réseau

Heu, y'aurais moyen d'avoir ton source pour ce chat client/serveur histoire de voir le fonctionnement et la grosse différence avec ce que je veux faire..
 
Merci!

oki quand ce sera fait, je t'enverrais un PM!

Merci !!!
Ca me permettra de voir un peu plus loin
que mon prog de m...