Incompatibilité Client Java - Serveur C++

Résolu
Saltoune Messages postés 3 Date d'inscription jeudi 2 novembre 2000 Statut Membre Dernière intervention 3 décembre 2004 - 3 déc. 2004 à 16:44
Saltoune Messages postés 3 Date d'inscription jeudi 2 novembre 2000 Statut Membre Dernière intervention 3 décembre 2004 - 9 déc. 2004 à 15:13
Bonjour,

Je développe en robotique un client Java pour un serveur C++ communiquant par TCP/IP avec un protocole inventé : Pour ce qui nous intéresse, lorsque le serveur reçoit la commande "ping;", il envoit la commande "pong;" et je calcule la durée entre l'envoi et la réception au niveau du client.
J'ai développé dans ce cadre un client C++ et j'obtiens un temps de 2ms (ce qui est normal). Mais avec le client Java, j'obtiens au mieux 133ms (j'ai bien entendu vérifier avec ethereal la durée entre les 2 ACK si le problème ne venait pas du réseau... mais point du tout!).
Brièvement, j'ai une classe ClientInputStream wrappant un BufferedInputStream avec des Thread et dans la méthode run(), j'effectue :

int c;
while (((c = super.read()) != -1) && (super.available() > 0))
{
client.receive((char)c); // client étant la référence à ma classe Client
}

Le problème ne vient pas du fait que le read s'effectue sur un octet car le délai provient du premier read effectué. Je ne sais pas s'il y a incompatibilité entre les sockets Berkeley C++ et Java ou si le BufferedInputStream met un temps (innommable!!!) à bufferiser son flux de caractères. Le calcul de la durée s'eefectue avec l'appel système System.currentTimeMillis(). Si quelqu'un pouvait m'aider car effectuer du temps-réel avec un ping de 133ms, c'est un peu mort!!!!

Ah oui, j'oubliais : j'effectue aussi du traitement d'image. Pour cela j'utilise un DataInputStream et sa méthode readFully pour lire un buffer de données binaires et je reçois les jpeg de 1,5ko en 30ms. C'est un peu incompréhensible!!

1 réponse

Saltoune Messages postés 3 Date d'inscription jeudi 2 novembre 2000 Statut Membre Dernière intervention 3 décembre 2004
9 déc. 2004 à 15:13
Pour ceux interessés, j'ai découvert d'ou provenait le problème:

Mon thread de lecture se bloquait sur un read et passait donc la main au thread principal (chose qui ne se passait pas avec le readFully car dans le cas ou je l'utilisais, j'étais sur de recevoir le bon nombre d'octets de données).
Lorsque de nouveaux octets arrivaient et qui débloquaient le read, le délai de 133ms était du à l'ordonnanceur des processus de la JVM qui mettait un temps très long à stopper le thread principal et à rendre la main au thread de lecture (à qui j'avais donné la priorité maximal, cad. 10).
J'ai résolu partiellement le problème en me rabattant sur le package java.nio (valable à partir de la jdk 1.4) et les SocketChannel qui proposent des lecture / écriture non bloquantes. J'arrive à un temp de ping de 20ms en moyenne. Ce n'est pas extraordinaire (il faut encore que j'optimise les transmissions pour passer la barre des 10ms), mais c'est toujours mieux que rien.

Si parmi vous existe un programmeur Java temps réel qui pourrait m'aider à optimiser mes entrées / sorties, je lui serai très reconnaissant s'il pouvait m'apporter ses précieux conseils.

Bon code à tous.
3
Rejoignez-nous