serveur sans blocage et thread sécurisé

J'ai un serveur qui utilise un thread pour recevoir des paquets de données UDP à partir d'une source de données distante; et TCP ServerSocket pour écouter les clients distants et générer un thread dédié pour chaque client. Je veux transférer chaque DatagramPackets via le ServerSocket aux clients multiples. Et maintenant j'ai rencontré une perte de paquets significative. Quelqu'un pourrait-il donner un conseil? Merci d'avanceserveur sans blocage et thread sécurisé

Source

2010-11-12 Dingxin Xu

Où (entre le serveur et la source de données ou le serveur et les clients) et dans quelle direction rencontrez-vous cette perte de paquets significative? –

Peut-il être juste un mauvais choix de protocoles dans la conception? Quelque chose censé être fiable pour plusieurs clients, car vous utilisez TCP. Mais la fiabilité a échoué en raison de la dépendance à l'égard du couplage en creux UDP (pontage/réémission) du côté serveur.

UDP est plus ou moins applicable pour des applications fiables, si vous tenez compte du fait que les paquets seront perdus par conception.

Solution 1: le changement protocole
Solution 2: si pas possible de changer le protocole, puis modifier les attentes de l'utilisateur sur le côté client sur la qualité du service
Solution 3: ajouter de la redondance à côté UDP pour répéter les demandes , les données de stock à l'avance en attendant de futures baisses de qualité, maintenir un grand cache accumulé de données pour nourrir les clients, peu importe quoi.

Source

2010-11-12 03:46:48

4. Réimplémenter TCP sur UDP O.o –

Merci pour votre réponse. Je crains que ce soit un problème typique de producteur-consommateur dans la programmation multi-thread. Et maintenant je me bats avec ça. Toute ligne directrice est appréciée. –

Il serait plus au point de se débarrasser de UDP à l'expéditeur plutôt que d'essayer de caser quelque sorte dans votre conception de TCP au niveau du récepteur, où il est déjà trop tard. Les paquets sont perdus entre l'expéditeur et le destinataire, pas dans votre récepteur. La fixation du code du récepteur ne résoudra pas le problème réel.

Source

2010-11-12 09:05:24 EJP

Sans savoir quoi que ce soit au sujet de votre conception de l'application, je peux faire les suppositions suivantes:

Votre UDP source envoie plusieurs paquets que votre récepteur peut gérer causer des paquets à supprimer, parce que
votre récepteur bloqués lors de la transmission des paquets aux clients TCP, car vos clients TCP ne ramassent pas les paquets assez rapidement provoquant le remplissage de la mémoire tampon (ce qui oblige le serveur à bloquer ce qui lui fait manquer les paquets UDP).

Source

2010-11-12 09:30:44

Merci pour votre réponse. J'ai localisé la cause de la perte de paquets, et c'est exactement ce que vous avez dit. Le tampon de réception est partagé par le thread de réception UDP et le thread d'envoi TCP, ce qui entraîne une perte de paquets si les threads expéditeurs ne terminent pas le processus d'envoi avant l'arrivée des nouveaux paquets. J'ai essayé le mécanisme wait-notify pour planifier ces threads d'écriture et de lecture, mais il se verrouille facilement. Comme je n'ai pas beaucoup d'expérience de programmation multi-threading, je ne sais pas s'il existe d'autres mécanismes. Pourriez-vous s'il vous plaît donner une suggestion? Grand merci! –

@Xu DXn: Essayez d'utiliser quelque chose comme [BlockingQueue] (http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/BlockingQueue.html) ou [ConcurrentLinkedQueue] (http : //download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/ConcurrentLinkedQueue.html). Peut-être une file d'attente par connexion TCP.Mais vous devrez faire face à la possibilité que vous receviez plus de paquets UDP qu'un ou plusieurs de vos clients TCP peuvent gérer et décider lesquels vous allez jeter. –

serveur sans blocage et thread sécurisé

Répondre

Questions connexes