Discussion :

[dbrondy]

Bonjour à tous,

Voilà, je cherche un peu d'aide sur les socket TCP JAVA.
Nous avons deux composants JAVA qui discutent entre eux via Socket. L'un est serveur, l'autre est client. Jusque là rien de bien exceptionnel.

Via ces deux composants, nous échangeons du serveur vers le client des paquets de donnée hexa de taille variable.
Actuellement, nous envoyons directement chaque buffer de donnée utile sur la socket via OutputStream.write(buffer[]).

Tout marche convenablement. Cependant, en utilisant nos deux composants au travers d'une liaison réseaux bas débit et qui plus est assez chargée, nous recevons de temps à autre coté client, deux (ou plus) paquets de donnée utile en un seul OU l'inverse plusieurs paquets de donnée utile en un.
=> problème coté client.

Au travers de mes lectures, il est bien spécifié dans TCP que ces cas particuliers peuvent arriver cependant, il me vient une question : peut-on se sortir de cette fragmentation / agrégation de donnée facilement sans implémenter une couche additionnelle qui entourerait notre donnée utile ? Par exemple, un header et tailer avec la taille de la donnée utile ...

J'ai beau vérifier notre code et il me semble que la lecture coté client est correctement effectuée...
J'avoue sécher un peu. Rassurer moi, je ne suis pas le seul dans ce cas ? Qu'avez-vous fait pour vous en sortir ?

Merci d'avance,
denis

[tchize_]

l'outputstream n'est qu'un stream. A vous de définir au dessus le protocole au dessus pour identifier et lire correctement vos paquet. Vous n'avez aucun garantie sur les tailles lue par un appel à read()

[dbrondy]

Bonjour et merci pour la réponse tchize_

C'est bien ce à quoi je m'attendais
Nous allons donc implémenter un mini protocole encapsulant au dessus.

Par contre, du coup en terme d'interopérabilité entre différentes applications, un autre programme écrit par exemple en C++ venant se connecter sur notre serveur JAVA devra lui aussi implémenter le dit protocole d'agrégation / segmentation de la donnée...
Je pensais qu'il y avait un moyen plus "générique" pour palier à cela.

Sinon tchize_ as-tu déjà vu un genre de protocole dont je pourrais m'inspirer ? Et à tout hasard, connaitrais tu un discriminant permettant d'identifier si le client implémente ou pas ce protocole (tout ca pour ne pas surcharger la donnée utile avec ce protocole si le client ne sais pas quoi en faire...client en C++ par exemple) ?

Merci pour tout,
denis

[tchize_]

Par contre, du coup en terme d'interopérabilité entre différentes applications, un autre programme écrit par exemple en C++ venant se connecter sur notre serveur JAVA devra lui aussi implémenter le dit protocole d'agrégation / segmentation de la donnée...
Je pensais qu'il y avait un moyen plus "générique" pour palier à cela.

Qu'il y aie ce problème de longeur de paquet ou pas, il le fait déjà. On ne parle pas à un serveur FTP comme on parle à un serveur web ou comme on parle à un serveur Jabber. Pourtant, il existe des implémentations pour chaque dans tout un tas de language. Le problème de la taille de vos données n'est qu'une considération mineure dans le reste du protocole.
Exemple en FTP: le \n marque la fin de la commande
En HTTP, la ligne vide marque la fin de la requete, et dans la réponse on a un content-length
Etc.
Tout ce qui peut etre abstrait l'est fait, vous est au niveau de vote application, niveau ou vous définissez votre protocole de discussion. Il existe des protocole "standard" comme soap ou corba pour faire de l'objet, mais vous aurez toujours une couche à ajouter au dessus.

[dbrondy]

Merci pour les exemples.
Effectivement, il va falloir donc enrober tout çà !

Dommage pour ce mineur problème de taille de paquet... je croyais que TCP était encore plus fort que cela ;-)