Java et TCP - Java - Programmation
Marsh Posté le 06-03-2004 à 23:21:26
les paquets IP arrivent peut être dans le désordre, mais le protocole TCP de la couche supérieur fournit un mode connecté, type flux, donc tout arrive dans l'ordre au niveau applicatif. tu écris à coup de 1024 byte dans ton OutputStream, certes, mais tu as l'assurance que tout arrive dans l'ordre
Marsh Posté le 07-03-2004 à 16:23:49
Taz a écrit : les paquets IP arrivent peut être dans le désordre, mais le protocole TCP de la couche supérieur fournit un mode connecté, type flux, donc tout arrive dans l'ordre au niveau applicatif. tu écris à coup de 1024 byte dans ton OutputStream, certes, mais tu as l'assurance que tout arrive dans l'ordre |
Merci
Autre question, sais tu comment allouer plus de mémoire a une classe ?
J'ai un outofmemory error semble t il suite a l'utilisation de la classe vector
Marsh Posté le 07-03-2004 à 16:46:42
Xavier- a écrit : |
doit y avoir une couille dans ton prog : ce que veut dire l'exception c'est que ton prog a bouffé toute la mémoire disponible sur ton PC ...
Marsh Posté le 07-03-2004 à 16:47:47
-Xmxn Specifies the maximum size of the memory allocation pool. This value must be greater |
cela dit t'as peut être un problème avec ton appli
Marsh Posté le 07-03-2004 à 16:50:38
Xavier- a écrit : |
C'est pas la mémoire allouée à ta classe que tu as bouffé, c'est la mémoire allouée à la jvm entière. C'est certainement un problème au niveau de ton code, pas au niveau de la quantité de mémoire disponible.
Marsh Posté le 07-03-2004 à 17:02:02
Je viens de dégager le vector, j'ai mis un StringBuffer a la place, ca marche mieux
J'ai fait un programme qui envoi un fichier par l'intermédiaire des sockets
Etant donné que le prof m'impose de trier les données recues je ne vois pas d'autre facilité que stocker toutes les données dans un StringBuffer en vue de les trier par la suite
Il semble que j'arrive a copier des fichiers entre 15 et 20 megas
Merci pour toutes vos reponses sinon
Marsh Posté le 07-03-2004 à 17:04:19
Xavier- a écrit : Je viens de dégager le vector, j'ai mis un StringBuffer a la place, ca marche mieux |
Par defaut, la taille minimum du pool d'allocation doit etre de 32 Mo. Donc même avec un fichier de 15-20 Mo, il n'y a aucune raison que tu satures la mémoire, à moins de charger le fichier deux fois. C'est peut-être au niveau de ton algo de tri qu'il y a un problème de mémoire...
Sinon je comprends pas bien comment tu peux "stocker toutes les données dans un StringBuffer en vue de les trier par la suite
" ?
Marsh Posté le 07-03-2004 à 17:14:37
R3g a écrit : Par defaut, la taille minimum du pool d'allocation doit etre de 32 Mo. Donc même avec un fichier de 15-20 Mo, il n'y a aucune raison que tu satures la mémoire, à moins de charger le fichier deux fois. C'est peut-être au niveau de ton algo de tri qu'il y a un problème de mémoire... |
si il stocke les données à cout de vector.add(new Byte(...))
Marsh Posté le 07-03-2004 à 17:30:02
R3g a écrit : Par defaut, la taille minimum du pool d'allocation doit etre de 32 Mo. Donc même avec un fichier de 15-20 Mo, il n'y a aucune raison que tu satures la mémoire, à moins de charger le fichier deux fois. C'est peut-être au niveau de ton algo de tri qu'il y a un problème de mémoire... |
****CLIENT****
- Le client ouvre un fichier et stock son contenu dans un buffer
- Vue que les données peuvent arriver dans le désordre, le client rajoute a chaque buffer qu'il va envoyer une en-tete avec la taille totale du fichier, la taille défaut d'un buffer (ex 1024 octets), le numéro de ce buffer
- Il envoi par buffer de 1024 octets le contenu de ce fichier au serveur
****SERVEUR****
- Il stock toutes les données recu dans un StringBuffer
- Il converti ce StringBuffer en String
- Il récupère la taille totale du fichier et creer un buffer correspondant (ca doit expliquer pkoi je peux pas gérer les fichiers de plus de 32/2 = 16 meg...)
- Il fait des recherches dans la chaine de caractere (à l'aide de la méthode indexOf("délimiteur utilisé" )) trouve le message correspondant, sa position... et le stock dans le buffer à la position calculée. A la fin mon buffer contient l'intégralité du fichier
- Il copie le buffer dans un fichier
Marsh Posté le 07-03-2004 à 17:36:59
Xavier- a écrit : |
Je pense que ta première solution avec un Vector était plus propre. Moi j'aurais fais comme ça : le serveur place les messages reçus dans un Vector, au besoin en les encapsulant dans un objet qui implement Comparable pour faciliter le tri, ensuite trie les éléments du Vector et écrit directement dans le fichier de sortie.
Marsh Posté le 06-03-2004 à 23:17:09
Salut tout le monde,
Voila dans le cadre d'un projet a présenter jeudi prochain je réalisé une class pour envoyer un email *sans javamail*
Donc j'utilise les sockets et je passe en mode TCP. J'ouvre un port vers le port 25 du server (enfin classique quoi) et j'envoi le contenu d'un fichier (contenant mon email) par buffer de 1024 octets.
Seulement voila, le prof me demande de numéroter les packets car je n'ai aucune assurance qu'ils arriveront dans l'ordre.
Je suis assez surpris pour deux raisons :
1) la classe que j'ai faite pour recevoir les emails (par pop3) fonctionne très bien et le server ne m'envoi strictement rien en dehors du fichier (aucune numérotation)
2) j'utilise une connexion par TCP, donc (si mes souvenirs du cours de réseau sont bons) en mode connecté, donc theoriquement tous les packets empruntent le meme chemin. Je ne vois en aucune facon comment les packets pourraient arriver dans le désordre dans de telles conditions...
Peut être arrivent-ils dans le désordre mais ceci est géré par le systeme d'exploitation...?
Explications ??
Message édité par xavier- le 06-03-2004 à 23:18:06