Bonjour a vous,

J'ai un code java qui tourne sur un emulateur android. Le code ouvre une Socket et communication avec un serveur distant. Le serveur distant est pour l'instant moi au bout d'un netcat ("nc -l"). Mon probleme est que malgre un appel a close() sur la socket, netcat ne rend pas la main. Ca veut dire que la connexion TCP n'est pas proprement ferme. Si je tue l'application java, netcat termine immediatement.

J'ai essaye de fermer tous les flux en court d'utilisation (ce qui devrait decouler de Socket.close, mais bon ) et d'appeller Socket.shutdownInput() et Socket.shutdownOutput(). Mais la connexion TCP ne se termine toujours pas.

Une idee sur la facon de fermer la connexion TCP ?

Ca peut t'aider peut-être :
http://download.oracle.com/javase/1.5.0/docs/guide/net/articles/connection_release.html

Après je sais pas comment marche netcat. Enfin souvent la plupart des protocoles RFC ont un message "QUIT" afin de ne pas s'appuyer que sur la couche TCP en cas de fin de l'échange non brutale.

Merci. Je ne sais pas si ca va m'aider a resoudre mon probleme. Mais au moins ca m'a rappeller qu'il y avait deux facon de terminer une connexion TCP.

mmm. En fait mon probleme etait different...
J'ai un thread de lecture bloque en lecture sur un bufferedreader du flux d'entree de la socket.

Dnas le thread qui interrompt la communication, je faisais sock.close() qui est cense fermer tous les flux de communication et debloquer le thread en lecture. Appeler sock.shutdownInput() debloque le thread de lecture proprement et ensuite sock.close() ferme la socket proprement.

Mon probleme est maintenant regler, mais je ne comprends pas pourquoi il faut appeller sock.shutdownInput(). J'imagine que sock.close() ne ferme pas la connexion parcequ'il y a des operations de lecture en cours. (bien que selon la page pointe par skip ca devrait ferme la socket proprement. Cependant, on dirait qu'il y a des difference entre J2SE et android. Par exemple, la fonction Socket.setLinger s'appelle maintenant Socket.setSoLinger()). J'imagine que shutdownInput() ferme le flux d'entre malgre l'operation en cours.

Si quelqu'un a une explication, je suis prenneur.

J'ai envie de te dire que ma premiere reaction est "qu'on vienne pas me dire que Java est toujours facilement portable". Sinon j'ai malheureusement aucune idee

C'est marrant je sens d'avance que je vais me faire taper sur les doigts pour ma remarque.

tbop2 Voir le profil de tbop2
Posté le 6 juin 2011 à 11:07:36 Avertir un administrateur
J'ai envie de te dire que ma premiere reaction est "qu'on vienne pas me dire que Java est toujours facilement portable".

DalvikVM n'est pas une JVM java standard.

Certes, mais elle le devrait !

Va dire ça à google, surtout qu'ils sont en procès à cause d'elle justement. Mais encore, les différences entre dalvik et une implémentation J2SE sont minimes pour ce qui est comparable.

Je sais, la bataille est severe d'ailleurs de ce que j'en ai entendu parler.

C'est une bataille de brevets, et les brevets logiciels aux US c'est que de la saloperie. N'empêche que ce procès remet en question beaucoup de préjugés sur le côté "open source" de java.

La portabilite de java est relativement pipeau de toute facon. La portabilite de n'importe quoi est relativement pipeau.

Si tu ecris une application pour PC tu suppose que tu as un ecran qui est relativement grand alors que si tu ecris une application pour un telephone, tu as un ecran qui est petit. Il va falloir reecrire une partie de l'application pour s'adapter (dans la majorite des applications non triviale). Apres ce port peut etre plus ou moins difficile a faire. Mais il va falloir porter.

La portabilite, c'est surtout un probleme de compatibilite de code. En faisant un peu de travail de compilateur, tu peux arriver a compiler du C pour la JVM. (ca a peut etre deja ete fait d'ailleurs.)

godrik Voir le profil de godrik
Posté le 6 juin 2011 à 20:49:13 Avertir un administrateur
La portabilite de java est relativement pipeau de toute facon. La portabilite de n'importe quoi est relativement pipeau.

Pas tout à fait d'accord.
La portabilité inter-OS est assurée en java si on y fait un minimum attention, et pas seulement pour les applications triviales.
Après la portabilité d'une application desktop sur un terminal mobile à juste aucun sens dans le sens où, comme tu le soulignes, le produit fini n'est pas le même.

L'argument de portabilité de java est donc assez réel, en revanche il faut garder à l'esprit que c'est pas forcément ce que demande un client.
Bref, du cas par cas.

On reviendra de toute facon sur le probleme de la propriete de dalvik mais a ce stade de la couche reseau on peut clairement dire que la portabilite est relative. Mais on en revient au probleme de la propriete de dalvik je suis bien d'accord.

J'entends pas relative : "non-assuree a coup sur".

• par

Ce que google a cherché à faire avec dalvik, c'est surtout de s'imposer grâce à la popularité et la richesse du monde java. C'était un avantage sur la concurrence de profiter de l'importante communauté de développeurs java en excellente santé.

IPhone : Objective C, fait gerber tous les non mac-addicts.
Symbian : C++ (euh lol?), ils se sont bien améliorés mais ayant essayé de développer sur du nokia à l'époque du S60, quelle daube!!!
Window mobile : .NetCf, intéressant au départ mais à la ramasse au fil des versions, puis très limité en interaction sur les périphériques.
J2Me : Un ensemble de "bullshit specification" à demi respectées par les fabricants, API arriérée comme jamais et outils dégueulasses.

Bref j'ai beau pas aimer Apple, je dois reconnaître qu'en venant avec leur iPhone et une API claire et homogène, ils ont foutu un coup de pieds dans la fourmilière qui a été très bénéfique au monde du développement sur mobile.

J'ai connais plein des entreprises de développement sur mobile qui ont pensé, vers 2003-2005 que c'était le futur et qu'il y avait un marché à prendre. Elles se sont toutes (ou presque) plantées la gueule.