Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1136 connectés 

  FORUM HardWare.fr
  Programmation
  Java

  Java et TCP

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Java et TCP

n°665686
xavier-
Futur président
Posté le 06-03-2004 à 23:17:09  profilanswer
 

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* :non:
 
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. :cry:  
 
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...? :heink:  
 
 
Explications ?? :??:


Message édité par xavier- le 06-03-2004 à 23:18:06
mood
Publicité
Posté le 06-03-2004 à 23:17:09  profilanswer
 

n°665687
Taz
bisounours-codeur
Posté le 06-03-2004 à 23:21:26  profilanswer
 

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

n°666149
xavier-
Futur président
Posté le 07-03-2004 à 16:23:49  profilanswer
 

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


Message édité par xavier- le 07-03-2004 à 16:27:20
n°666192
benou
Posté le 07-03-2004 à 16:46:42  profilanswer
 

Xavier- a écrit :


J'ai un outofmemory error semble t il suite a l'utilisation de la classe vector


[:le kneu]
 
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 ...

n°666193
Taz
bisounours-codeur
Posté le 07-03-2004 à 16:47:47  profilanswer
 

      -Xmxn               Specifies the maximum size of the memory allocation pool.  This value must be greater
                           than  1000.   To modify the meaning of n, append either the letter k for kilobytes or
                           the letter m for megabytes.  The default value is 64m.  The  uppoer  limit  for  this
                           value  will  be  approximately  4000m  on SPARC platforms and 2000m on x86 platforms,
                           minus overhead amounts.


 
cela dit t'as peut être un problème avec ton appli


Message édité par Taz le 07-03-2004 à 16:49:21
n°666196
R3g
fonctionnaire certifié ITIL
Posté le 07-03-2004 à 16:50:38  profilanswer
 

Xavier- a écrit :


 
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

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.


---------------
Au royaume des sourds, les borgnes sont sourds.
n°666207
xavier-
Futur président
Posté le 07-03-2004 à 17:02:02  profilanswer
 

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

n°666211
R3g
fonctionnaire certifié ITIL
Posté le 07-03-2004 à 17:04:19  profilanswer
 

Xavier- a écrit :

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

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
" ?


---------------
Au royaume des sourds, les borgnes sont sourds.
n°666216
benou
Posté le 07-03-2004 à 17:14:37  profilanswer
 

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...
Sinon je comprends pas bien comment tu peux "stocker toutes les données dans un StringBuffer en vue de les trier par la suite
" ?


si il stocke les données à cout de vector.add(new Byte(...)) :/

n°666229
xavier-
Futur président
Posté le 07-03-2004 à 17:30:02  profilanswer
 

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...
Sinon je comprends pas bien comment tu peux "stocker toutes les données dans un StringBuffer en vue de les trier par la suite
" ?


 
****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

mood
Publicité
Posté le 07-03-2004 à 17:30:02  profilanswer
 

n°666236
R3g
fonctionnaire certifié ITIL
Posté le 07-03-2004 à 17:36:59  profilanswer
 

Xavier- a écrit :


 
****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

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.


---------------
Au royaume des sourds, les borgnes sont sourds.

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  Java

  Java et TCP

 

Sujets relatifs
Java et BDD accessbase Access et Java grrrrrrrrrrrr
IPC avec JAVA[JAVA] NullPointer Exception : JVM Symantec ???
[WBEM] Comment peut on connaitre la config de son PC en java ??[JAVA][RESEAU]Problèmes sockets TCP/IP
[Java]TCP Client ne marche que partiellement pkoi?[Resolu][JAVA]pour les pros: sniffeur TCP/IP
[enfin un peu de JAVA] Transfert de fichiers par TCP/IPjava sniffer TCP
Plus de sujets relatifs à : Java et TCP


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR