[java] - Classe Vector
arth
Messages postés
10414
Date d'inscription
Statut
Contributeur
Dernière intervention
-
Marco la baraque Messages postés 1030 Statut Contributeur -
Marco la baraque Messages postés 1030 Statut Contributeur -
Bonjour bonjour,
Aujourd'hui c'est moi qui poste.
Je suis en train de faire une application pour uploader des fichiers sur un serveur, ce n'est pas là sa seule utilité mais c'est celle-ci qui me pose problème.
En effet il m'a semblé voir quelque part que la classe Vector était gourmande en ressources et qu'il était préférable d'en utiliser une autre mais je ne me souviens plus laquelle? List ? JList?
Parce que mon upload se fait bien mais il me semble lent. Donc j'aurais voulu essayer avec cette autre classe.
Si Marco ou quelqu'un voit de quoi je parle :)
Si vous voulez du code je vous en donne.
Aujourd'hui c'est moi qui poste.
Je suis en train de faire une application pour uploader des fichiers sur un serveur, ce n'est pas là sa seule utilité mais c'est celle-ci qui me pose problème.
En effet il m'a semblé voir quelque part que la classe Vector était gourmande en ressources et qu'il était préférable d'en utiliser une autre mais je ne me souviens plus laquelle? List ? JList?
Parce que mon upload se fait bien mais il me semble lent. Donc j'aurais voulu essayer avec cette autre classe.
Si Marco ou quelqu'un voit de quoi je parle :)
Si vous voulez du code je vous en donne.
A voir également:
- [java] - Classe Vector
- Jeux java itel - Télécharger - Jeux vidéo
- Waptrick java football - Télécharger - Jeux vidéo
- Waptrick java voiture - Télécharger - Jeux vidéo
- Java apk - Télécharger - Langages
- Eclipse java - Télécharger - Langages
30 réponses
La surcharge des appels rmi est minime (je veux dire: dans un packet contenant des données, la partie représentant autre chose que les données utiles - dans ton cas le tableau de bytes ou le String - est négligeable). Du coup, dans ce cas bien précis, des appels rmi avec une méthode ayant comme paramètre uniquement le tableau de bytes (par exemple) devraient être très performants en termes de transfert réseau.
Si je dis une bêtise, c'est que, une fois de plus, je devrais relire avec attention les spécifications avant de me lancer :-)
Si je dis une bêtise, c'est que, une fois de plus, je devrais relire avec attention les spécifications avant de me lancer :-)
Après vérification: http://lisas.de/~adrian/master/rmi.pdf chapitre 5.2 ==> RMI consommerait bien plus de bande passante que des appels sockets. Mais bon, de mon expérience pas si sûr que ça (et aussi infirmé par la figure 1 du même pdf où on voit un ratio de 1.3/1.5...) Faudra 'têtre creuser un peu pour les détails (lire tout le pdf* et aussi des spécs & plus de chez Sun)
*: pfff, quelle idée :)
*: pfff, quelle idée :)
J'avoue quelle idée :) Si tout le monde était un Geek aussi :) on devrait faire des manifs pour ça !!
Quelque soit ton choix, je me permets de répondre sur la question de l'utilité de transférer les données en format XML (idée suggérée plus haut) :
Je proposais cette solution dans le cas où les sockets sont utilisées uniquement.
En effet, tu dois transférer des fichiers dont les données varient, mais il me semble important d'en maitriser la structure si tu souhaite faire des contrôles sur leur contenu, et éventuellement faire un traitement derrière.
Il faut bien noter que la structure XML serait à utiliser pour "coder" des informations dans un squelette XML de sorte à pouvoir les comprendre coté serveur à la réception, s'il s'agit de données à analysée uniquement.
Si tu ne souhaite que transférer des "map" ou autre fichier image, dont le format est bien spécifique à un jeu, tu pourra simplement les transférer par tableau de byte comme il a déjà été dit avant dans plusieurs post.
Mais dans l'exemple suivant : tu veux transférer les données suivantes : la map "XXX" comporte "YY" monstres. Les monstres sont les suivants : "ojoijoij", "oijoijioj", "oijoijoij", etc.
Tu peux coder ces informations selon une structure XML:
Ainsi coté serveur tu peux facilement faire un parseur java qui récupère tes données pour, par exemple, remplir une base de données, etc.
Voilà, donc l'XML était précaunisé au cas où tu doives transférer des fichiers de données à interpréter.
Je proposais cette solution dans le cas où les sockets sont utilisées uniquement.
En effet, tu dois transférer des fichiers dont les données varient, mais il me semble important d'en maitriser la structure si tu souhaite faire des contrôles sur leur contenu, et éventuellement faire un traitement derrière.
Il faut bien noter que la structure XML serait à utiliser pour "coder" des informations dans un squelette XML de sorte à pouvoir les comprendre coté serveur à la réception, s'il s'agit de données à analysée uniquement.
Si tu ne souhaite que transférer des "map" ou autre fichier image, dont le format est bien spécifique à un jeu, tu pourra simplement les transférer par tableau de byte comme il a déjà été dit avant dans plusieurs post.
Mais dans l'exemple suivant : tu veux transférer les données suivantes : la map "XXX" comporte "YY" monstres. Les monstres sont les suivants : "ojoijoij", "oijoijioj", "oijoijoij", etc.
Tu peux coder ces informations selon une structure XML:
<map name="XXX">
<monstres>
<monstre name="iojoij" />
<monstre name="iojfsdfs" />
</monstres>
</map>
Ainsi coté serveur tu peux facilement faire un parseur java qui récupère tes données pour, par exemple, remplir une base de données, etc.
Voilà, donc l'XML était précaunisé au cas où tu doives transférer des fichiers de données à interpréter.
En fait non les fichiers maps son composés de plusieurs fichiers mais l'extension n'a pas d'importance.
La plupart du temps ces fichiers sont mis ensemble dans un seul fichier zip.
Ce que j'avais pensé à faire :
- upload par l'application du fichier zip
- décompression de l'archive via un script shell et copie des fichiers dans les bons répertoires.
Le xml je voyais plutôt ça pour définir un protocole de transfert.
Genre si je veux uploader une map, j'envoie un mot type <datamap> pour signifier que je vais envoyer une map
Parce que le souci c'est aussi comment récupérer le nom du fichier côté serveur pour créer le même nom de fichier en local de celui-ci?
Pour cela qu'il faudrait dire au serveur que l'on va uploader une map, un son, etc. Puis quel est le nom du fichier. Et enfin les données qu'il contient. Puis envoyer un mot type </datamap> pour signaler que le fichier peut être fermé côté serveur et qu'on a plus de donnée à envoyer.
La plupart du temps ces fichiers sont mis ensemble dans un seul fichier zip.
Ce que j'avais pensé à faire :
- upload par l'application du fichier zip
- décompression de l'archive via un script shell et copie des fichiers dans les bons répertoires.
Le xml je voyais plutôt ça pour définir un protocole de transfert.
Genre si je veux uploader une map, j'envoie un mot type <datamap> pour signifier que je vais envoyer une map
Parce que le souci c'est aussi comment récupérer le nom du fichier côté serveur pour créer le même nom de fichier en local de celui-ci?
Pour cela qu'il faudrait dire au serveur que l'on va uploader une map, un son, etc. Puis quel est le nom du fichier. Et enfin les données qu'il contient. Puis envoyer un mot type </datamap> pour signaler que le fichier peut être fermé côté serveur et qu'on a plus de donnée à envoyer.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Parce que le souci c'est aussi comment récupérer le nom du fichier côté serveur <== disons que tu as une méthode
public void fileTransfer(String fileName, byte[] data) throws EnterpriseException, RemoteException;
==> tu renseignes le nom du fichier et les données à transférer en tant que paramètres de la méthode. Si appel à fileTransfer() depuis des threads non ordonnacés, il faudrait également un paramètre pour préciser le numéro de la séquence dans le découpage de fichier...
public void fileTransfer(String fileName, byte[] data) throws EnterpriseException, RemoteException;
==> tu renseignes le nom du fichier et les données à transférer en tant que paramètres de la méthode. Si appel à fileTransfer() depuis des threads non ordonnacés, il faudrait également un paramètre pour préciser le numéro de la séquence dans le découpage de fichier...
Oui, tout à fait d'accord avec kij concernant le xml à utiliser si l'on a besoin d'interpréter les données transférées. Des parsers validants (par rapport à des xsd-Schema) pouvant également être utilisés pour - par exemple - lever une exception du genre
et ceci sans trop se casser la tête sur l'implémentation.
Monstre iojfsdfs: longueur maximale définie pour le nom dépassée (max 7 caractères)
et ceci sans trop se casser la tête sur l'implémentation.
Pour ce qui est du protocol de transfert, le plus simple c'est de :
- lister les actions possible du client
- attribuer un numéro sur ces actions
Ainsi, lorsque le client souhaite faire quelque chose avec le serveur (hum hum :D), après avoir établie la connexion (après ouverture socket sur l'adresse du serveur), le programme client envoyer un entier correspondant au code de l'action.
Ainsi coté serveur, le code est interprété et appel une suite de procédure d'échange (attente d'une String pour le nom du fichier, puis de toute une série de byte[] jusqu'à ce que ce soit fini par exemple).
Et le client de son coté, une fois l'entier envoyé, appel la procédure d'échange qui correspond à l'action. (envoi du nom de fichier -> le serveur lit -> le serveur répond -> le client découpe les données, puis envoi le nombre de paquet à réceptionner (afin de faire une boucle coté serveur sur la réception) , et le client envoi les données du fichier (byte[]) -> le serveur réceptionne chaque paquet -> fin du transfert, le serveur renvoi une confirmation au client -> le client réceptionne la réponse. Fin de l'échange.
Bon c'est juste un exemple rapide hein ^^
- lister les actions possible du client
- attribuer un numéro sur ces actions
Ainsi, lorsque le client souhaite faire quelque chose avec le serveur (hum hum :D), après avoir établie la connexion (après ouverture socket sur l'adresse du serveur), le programme client envoyer un entier correspondant au code de l'action.
Ainsi coté serveur, le code est interprété et appel une suite de procédure d'échange (attente d'une String pour le nom du fichier, puis de toute une série de byte[] jusqu'à ce que ce soit fini par exemple).
Et le client de son coté, une fois l'entier envoyé, appel la procédure d'échange qui correspond à l'action. (envoi du nom de fichier -> le serveur lit -> le serveur répond -> le client découpe les données, puis envoi le nombre de paquet à réceptionner (afin de faire une boucle coté serveur sur la réception) , et le client envoi les données du fichier (byte[]) -> le serveur réceptionne chaque paquet -> fin du transfert, le serveur renvoi une confirmation au client -> le client réceptionne la réponse. Fin de l'échange.
Bon c'est juste un exemple rapide hein ^^
Bonsoir,
Surtout qu'en objet c'est assez sympa à réaliser.
Du côté serveur, la liste de tes actions possible est réalisée via une interface : toutes tes méthodes implémentent cette interface et définissent chacun un comportement.
Le serveur crée une instance d'une implémentation via une factory (suite aux paramètres envoyés par le client via xml). Les fichiers sont envoyés par socket (facile de passer des objets et tout), et le tour est joué.
En plus comme ça ton application est modulaire et tu peux en étendre le comportement.
Cordialement,
Surtout qu'en objet c'est assez sympa à réaliser.
Du côté serveur, la liste de tes actions possible est réalisée via une interface : toutes tes méthodes implémentent cette interface et définissent chacun un comportement.
Le serveur crée une instance d'une implémentation via une factory (suite aux paramètres envoyés par le client via xml). Les fichiers sont envoyés par socket (facile de passer des objets et tout), et le tour est joué.
En plus comme ça ton application est modulaire et tu peux en étendre le comportement.
Cordialement,
Marco faut que tu m'explicites ton dernier message :) parce que je vois bien le coup de l'interfacage mais uniquement pour RMI. Pour les sockets ça je n'ai pas encore vu, moi être modeste développeur java :)
Pour Kij => "lorsque le client souhaite faire quelque chose avec le serveur" on dirait que ça sent le vécu ;)
Pour Kij => "lorsque le client souhaite faire quelque chose avec le serveur" on dirait que ça sent le vécu ;)
Hello,
Oh rien de bien compliqué dans mes propos. Je dis juste que tu as une interface avec une méthode uploadFichier(Socket socket) par exemple, et que tu implémentes un ensemble de classes qui implémentent cette interface.
Comme ça tu peux très bien définir le comportement que tu souhaites en fonction du fichier xml envoyé (enfin, l'idéal est d'envoyer tout d'abord le fichier xml, de le parser, d'utiliser la factory pour créer la classe qui va bien, et enfin d'appeler uploadFichier de cette méthode).
De cette manière, si tu veux ajouter un comportement, il suffit juste d'enrichir la factory et de créer une nouvelle classe qui implémente ton interface.
Pour le transfert via socket, jette un oeil sur sardes.inrialpes.fr/~depalma/06/Midep/cours1.ppt, ça peut peut-être te guider un peu.
Cordialement.
Oh rien de bien compliqué dans mes propos. Je dis juste que tu as une interface avec une méthode uploadFichier(Socket socket) par exemple, et que tu implémentes un ensemble de classes qui implémentent cette interface.
Comme ça tu peux très bien définir le comportement que tu souhaites en fonction du fichier xml envoyé (enfin, l'idéal est d'envoyer tout d'abord le fichier xml, de le parser, d'utiliser la factory pour créer la classe qui va bien, et enfin d'appeler uploadFichier de cette méthode).
De cette manière, si tu veux ajouter un comportement, il suffit juste d'enrichir la factory et de créer une nouvelle classe qui implémente ton interface.
Pour le transfert via socket, jette un oeil sur sardes.inrialpes.fr/~depalma/06/Midep/cours1.ppt, ça peut peut-être te guider un peu.
Cordialement.
