> Une petite question (na ve) par rapport la m thode choisie, le select(). > Est-ce qu'il n'y a pas un risque d'encombrement l'entr e ? Si un grand > nombre de clients envoient des infos au serveur en "m me temps", il ne > risque pas d'y avoir des pertes quelques part ?
tout depends de la taille de l'info et de son temps de traitement si par ex il y a en meme temps 1000 clients qui envoient 1MB en ByteArray a chaque connection le recv() va bloquer le temps de recevoir le total du 1MB si on est en TCP donc oui, cela peut avoir un effet de "denial of service" DoS, car pendant que le serveur est bloqué pour recevoir ce 1MB d'un seul client, les autres 999 clients sont eux aussi bloqués mais ce bloquage depends de la bande passante du serveur (et aussi du client) ET du temps que le serveur met a traiter ce 1MB de données En soit il n'y a pas vraiment de pertes de données, enfin si aussi disons que le serveur a aussi l'option de backlog, cad mettre en queue les connections qu'il ne peut pas traiter tout de suite dans ce cas particulier, le serveur ne perdra pas les données des clients par rapport aau backlog si on a un backlog de 128 par ex, - 1er client on perds pas les données - 127 autres client sont mis en queue pendant que le 1MB du 1er client est traité par le serveur - les 872 autres connections sont perdus mais bon c'est quand meme un cas extreme où a exactement la meme seconde, 1000 clients envoient tous un gros paquet de 1MB et ca en fait ca peut se gerer au niveau du protocol, par ex definir un protocol qui ne peut envoyer que maximum 100KB de donnees par connections et si le client veut envoyer 1MB et bah ca split l'envoie en plusieurs paquets de 100KB ca complique le protocol mais ca a l'avantage de pouvoir marcher en TCP et UDP car dans le cas de l UDP par exemple rien qu a a cause du MTU, on peut a peu pres recevoir 1500bytes max par paquet (donc on doit de toute maniere splitter 1MB) bref, tout ca depends de l'application, du protocol et du hardware mais en soit select() ne perdra pas les données "juste comme ca" > Et au niveau de la quantit d'infos, est-ce que, lors d'envois de grosse > masse d'infos, il ne risque pas d'y avoir des pertes dans la loop ? en UDP, il y aura de la perte car UDP fontionne comme ca meme 1500bytes de données ne sont pas garantie d'arrivée idealement pour du UDP, pour etre safe, on gere max 512bytes de données en TCP, il n'y a pas vraiment de limites car TCP fonctionne differemment d'UDP, avec TCP on est en mode stream, cad que meme si la donnee qu on envoit est plus grosse que le plus gros paquet que peut supporter le protocol, tout ca est gerer comme un stream de données en fonction du buffer du recv() et des propriétés reseau (MTU etc.) si on envoit 1MB, on verra un split de la donnée en plusieurs paquets, mais ca en TCP c'est gérer automatiquement (par contre oui le temps de recevoir les grosses données, ca bloque) mais comme je le dis au dessus, ca peut se gerer au niveau du protocol cad la lib client et serveur qui envoie les données peut simplement choisir des limites, par ex 100KB max, et spliter/reassembler les données a a sa propre sauce > C'est un des probl mes que je rencontre avec l'utilisation des sockets > en PHP :s > > Comme je le disais, les questions sont peut- tre na ves... je ne suis > pas un expert mais plut t un utilisateur qui met beaucoup d'espoirs dans > redtamarin :) > Et a n'a rien voir avec ServerSocket de AIR... je ne sais pas du tout > si ces probl mes ne risquent pas d'arriver aussi avec cette classe... > c'est juste des questions que je me pose. > tout ce que je peux dire pour l'instant c'est que je suis assez sure de la partie "native" des sockets de redtamarin apres, l'autre gros boulot, c'est de mettre au point un protocol qui permet de gerer UDP et TCP (selon les besoins, par ex, un chat TCP ca suffit, et UDP pour un jeu temps reel ou on veut que le transfert de données aille plus vite) et gerer le split/reassemble des données mais rien de nouveau, c'est comme la limite des 40KB de données sur une LocalConnection, si on veut envoyer 1MB en LC il faut spliter en paquets de 40KB et reassembler a l'arrivée une fois qu on a un protocol comme ca, c'est plus du tuning coté logic serveur entre le temps maximum de loop et le temps de traitement des données en fait il faut voir TCP et UDP comme une "route a empruntée" mais il ne faut pas utiliser les protocols tel quel, il faut construire son propre protocol par dessus, comme le fait HTTP, FTP, etc. et en gros j'avais un peu commencé a penser a ca avec eden http://code.google.com/p/edenrr/wiki/MessagingProtocol a l'epoque je pensais gerer tout ca que en mode texte mais comme maintenant on peut faire du ByteArray des 2 cotés (client et serveur) et bah on peut faire un protocol en ByteArray donc (sans faire de l'AMF) ---- header option length option en string data length data en string ---- les options et datas peuvent rester du string en eden mais on peut envisager d'avoir le tout encapsuler dans du ByteArray > En tout cas, j'attends une petite d mo (tuto ?) avec impatience pour > voir comment a fonctionne concr tement... j'essayerais bien de le faire > moi-m me, from scratch mais je n'ai vraiment pas le temps maintenant :s > (et pourtant, ce n'est pas l'envie qui manque) bah j'avais prévu a peu pres 2 semaines, mais j'ai d autres choses qui sont arrivé entre temps donc ca ira un peu plus lentement mais oui a force il y aura une demo serveur redtamarin avec différent clients (redtamarin, SWF, AIR, etc.) en fait je pense que le plus gros probleme sera de trouver ou d'emuler 4000+ connections concurrentes , va falloir faire du buzz :p zwetan -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes FCNG. Pour envoyer un message à ce groupe, adressez un e-mail à [email protected]. Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse [email protected]. Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/fcng?hl=fr
