Fermeture de socket avec erreur

Question

Je suis en train d'écrire un tas de données sur une socket, cependant, après ce qui semble être écrit autour de 64k, le socket est fermé avec une erreur "Connection reset by peer". Je crois que ce qui se passe est que ce qui lit la socket (Android Media Player) est en train de mourir en essayant de lire plus de données que ce qui est disponible sur le socket. C'est une chanson qui est diffusée et quand la balise id3 est assez grande, elle échoue. Cependant, lorsque je supprime les informations id3 de la chanson, cela fonctionne très bien. Puisque je crois que le côté de lecture échoue quand il n'y a pas assez de données, je me demande s'il est possible d'écrire un tas de données au socket avant d'appeler socket.accept() pour accepter la connexion pour le lire . Ma pensée ici est que lorsque le lecteur multimédia se connecte à la socket, il y aura suffisamment de données pour qu'il puisse lire et donc ne pas tomber en panne. Alors pouvez-vous appeler write() avant d'accepter()?

Voici quelques psudocode de mon code actuel:

ServerSocket socket = new ServerSocket(port, 0, InetAddress.getByAddress(new byte[] {127,0,0,1})); 

    socket.setSoTimeout(10000); 
    port = socket.getLocalPort(); 

    Socket client = socket.accept(); 

    ... 

    while (isRunning && (readBytes = data.read(buff, 0, buff.length)) != -1) { 

     client.getOutputStream().write(buff, 0, readBytes);   

    } 

Answer 1

Cela signifie généralement que vous avez écrit à une connexion qui a déjà été fermée par l'autre extrémité. En d'autres termes, une erreur de protocole d'application. Le 64k représente probablement juste la quantité de tampon entre vous et le pair.

Votre question sur l'écriture sur le socket avant d'accepter() n'a pas de sens si elle fait référence au serveur. Cependant, si vous voulez dire le client écrit à la socket, cela peut en effet se produire. Le client peut se connecter, écrire (jusqu'à la limite de la mise en mémoire tampon disponible) et fermer avant que le serveur n'accepte un appel. Cela est dû à la file d'attente TCP «backlog» par laquelle la pile TCP termine les connexions de manière aynchrone et les met en file d'attente, prête à être acceptée par l'application.