IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage Java Discussion :

traffic client/serveur cryptage byte[] et detection de fin


Sujet :

Langage Java

  1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mars 2007
    Messages : 22
    Points : 19
    Points
    19
    Par défaut traffic client/serveur cryptage byte[] et detection de fin
    Bonjour, je développe un client/serveur en java. Différentes sécurités sont mises en oeuvre dont notamment un cryptage symétrique de la transmission réseau.

    Avant de passer sur le réseau, mes objets sont transformés en byte[], ce tableau représentant un objet est crypté à l'aide d'une clé.

    Ensuite, un bufferedoutputstream envoit ce tableau sur le réseau.

    Du côte serveur, je ne sais donc pas quelle est la taille de ce qui arrive, je lis byte par byte. Une fois que le client va faire une socket.close(), une exception EOF va être généré sur le serveur car la lecture byte se fait au plus bas sur un sicket.getinputstream.

    Mon soucis est que je ferme la connection, pour détecter la fin de transmission, je voudrais que le serveur puisse répondre sur la même socket. Mais comment faire ??? il faudrait un autre moyen que mon astuce EOF.

    Merci d'avance.

  2. #2
    Modérateur
    Avatar de dinobogan
    Homme Profil pro
    ingénieur
    Inscrit en
    Juin 2007
    Messages
    4 073
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France

    Informations professionnelles :
    Activité : ingénieur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 4 073
    Points : 7 163
    Points
    7 163
    Par défaut
    Une idée couramment utilisée : le premier octet envoyer au serveur peut être le nombre total d'octets à recevoir. Ainsi, tu auras tous les octets, et tu pourras en plus détecter une rupture de communication si tu n'as pas le bon nombre d'octets.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java
    Que la force de la puissance soit avec le courage de ta sagesse.

  3. #3
    Membre à l'essai
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mars 2007
    Messages : 22
    Points : 19
    Points
    19
    Par défaut
    Merci pour la réponse.

    Il y a la solution que tu viens de proposer et aussi celle d'un marqueur de fin de transmission.

    Mais je préfère envoyer la taille à lire car un marqueur peut être crée implicitement par l'encryption de mes données.

    Je viens d'implémenter le principe et ça a l'air de bien fonctionner .

    Merci encore.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Cryptage des requêtes Client-Serveur
    Par wassim_sfax dans le forum Servlets/JSP
    Réponses: 1
    Dernier message: 30/03/2013, 20h04
  2. Réponses: 3
    Dernier message: 23/08/2010, 15h10
  3. [Cryptage] Application client/serveur
    Par TelcharF dans le forum Bibliothèques
    Réponses: 5
    Dernier message: 19/07/2007, 21h51
  4. méthode de cryptage, appli client/serveur
    Par sir_gcc dans le forum Développement
    Réponses: 1
    Dernier message: 14/09/2005, 12h13
  5. Langage le mieux adapté pour application client serveur ?
    Par guenus dans le forum Débats sur le développement - Le Best Of
    Réponses: 4
    Dernier message: 17/06/2002, 15h46

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo