Impossible d'écouter le port ....

[Crone123]

Bonjour,
J'ai trouvé un petit bug au niveau du module réseau. (SFML 2.0 stable)
Dans certaines conditions, l'application deviens incapable d'écouter un port qui est pourtant libre.

Donc, Socket TCP, en mode non-bloquant, testé sous Linux.
Cas de figure qui bug:
1 - Lancer le serveur
2 - Connecter le client
3 - Shooter le serveur
4 - Relancer le serveur

Et:
1 - Lancer le serveur
2 - Connecter le client
3 - Shooter le serveur
4 - Shooter le client
5 - Relancer le serveur
Normalement le serveur ne peut pas écouter le port pendant quelques minutes. (Même si on shoot le client après, il faut quand même attendre).

En revanche dans ce cas de figure:
1 - Lancer le serveur
2 - Connecter le client
3 - Shooter le client
4 - Shooter le serveur
5 - Relancer le serveur

Fonctionnent parfaitement.

Le problème doit être un bug qui empêche d'écouter un port si un client a déjà une connexion ouverte dessus. (sf::TcpSocket::connect)
J'ai le bug assez fréquemment quand je développe les applis, et a force de l'avoir j'ai finis par voir ça
C'est pas un bug extrêmement important, mais ça fait quelques prises de tête si on l'as plusieurs fois quand on développe un truc.
Merci

[Lolilolight]

Oui j'ai aussi eu un bug comme ça une fois, j'ai du redémarrer carrément le PC car les port n'étaient pas libre.
Mais je me souviens plus vraiment dans quel cas c'était arrivé.
C'était surement quand j'avais sans le faire exprès fermé le serveur, puis fermé le client, puis relancer le serveur du coup je fais gaffe de toujours fermer le client en 1er.

[Crone123]

Moi c'est sur un serveur allumé depuis 2ans, donc c'est déjà bien que ça se libère au bout de quelques minutes parce que j'ai pas trop envie de le redémarrer toutes les 5min :p

ça t'était arrivé sous Windows ou Linux? (ou les2?)

Sinon, j'ai le bug depuis pas loin d'un an sur différentes machines, mais j'avais pas réussi a voir d'où ça venais...

[Lolilolight]

Ca m'est arrivé sous windows, mais ça m'est arrivé que une seule fois.
Je sais que sous linux j'ai eu quelques soucis donc je suis repassé sous windows, j'ai du réinstallé linux parce que j'avais pas assez de place sur le /home pour installer un jeux avec wine sur le home quand j'ai partitionner le disque dur du coup bon là je dois réinstaller toutes les librairies sous linux mais quand j'ai installé les dépendances nécessaire à la compilation de QT, le jeux ne marchais plus et ça me changeait carrément la résolution d'écran du bureau, donc..., j'ai laissé tombé linux et je suis repassé à windows, ainsi je dois pas rallumer le PC et passer de windows à linux quand je veux développé puis jouer.

J'ai pensé à la virtualisation mais mon prof m'a dit que c'étais déconseillé avec une version home de windows. (hors c'est ce que j'ai.)
Donc oui si tu développes sous linux tu risques d'avoir quelques soucis. :/
Car au niveau gaming tout a été fait à la base pour windows, linux possèdent juste des programmes qui essayent de faire fonctionner des applications windows sous linux mais c'est carrément de la mer de, c'est compréhensible vu que tout ce qui est issus de windows n'est pas opensource.

La SFML est sensé être opensource et utilisent des librairies opensource donc il ne devrait pas y avoir de problèmes mais j'ai quand même eu quelques soucis.

PS : j'ai essayer de redimentionner les partitions avant de réinstaller avec le live cd mais pas moyen, bref, je trouve que c'est un peu mal foutu. :/

J'ai déjà essayer plusieurs logiciel (partition suite entre autre.) mais soit ça marche pas ou alors ça fait planté ton système, je n'ai trouvé que un truc qui marche que sur xp.

Je sais que je sors un peu du sujet mais..., comme quoi parfois ce n'est pas impossible qu'on aie encore des soucis et qu'on doivent chercher des outils ou des librairies qui fonctionnent parce que parfois (voir même souvent.) ça ne fonctionne carrément pas.
Et si je veux te foutre un linux ou un windows en l'air voir même changer les mots de passe pour windows y'a facilement moyen, je vais pas dire comment mais y'a moyen. (Je parle bien sûr de changer les mots de passe sans rentrer dans windows.)
Avec linux tu passes partout. ^^

[Laurent]

C'est normal que le port reste indisponible quelques minutes. Du coup ce qui me paraît louche c'est plutôt ton exemple qui fonctionne : le port devrait tout être autant indisponible.

[Crone123]

Si tu as des problèmes avec une bibliothèque c'est propre a cette bibliothèque.
Perso j'ai Linux et Windows sur tous mes ordis, et j'ai aussi des machines virtuelles de a peu près tout.

Windows ne me sert que pour les jeux type Skyrim, BF3, bref, des jeux natif Windows. Linux me sert pour tout le reste.
Il existe de très bons jeux OpenSource pour faire des lan party sans avoir a payer une licence par joueur, c'est très appréciable.
En gros, si tu regardes: Le même programme, compilé nativement pour chaque système tourne mieux sous Linux que sous Windows.
Je suis d'accord avec toi que lancer Skyrim sur Linux c'est du pur suicide, mais non pas parce que le logiciel d'émulation est pourri, ou autre: Simplement parce que c'est un programme Windows et non pas Linux, faut pas chercher plus loin, c'est comme lancer un jeu de PS3 sur Windows ça reviens au même ça fait de la grosse m****.
Maintenant dire qu'au niveau gaming tout a été a la base fait pour Windows, c'est du grand n'importe quoi. La base, c'est DOS et UNIX, et les 2 étaient pareils. Les consoles de jeux comme la PS3 utilisent du Linux (ils ont rien d'autre de toute façon comme OS), et les smartphones qui deviennent des plateformes de jeux sont a 80% sous Android, donc sous Linux. Niveau PC, de plus en plus de jeux sont aussi développés pour Linux. C'est pas une question de performance ou de "base", c'est surtout question d'une grosse entreprise multinationale du nom de Microsoft qui tiens a se faire beaucoup d'argent en annihilant la concurrence.
Je rappelle que d'origine les jeux étaient tous OpenGL, et que Microsoft développait aussi OpenGL, les jeux étaient donc compatible tous OS il suffisait de compiler.
Microsoft a ensuite eu l'idée de sortir DirectX uniquement pour Windows pour restreindre la concurrence, et a fait le coup de bluff de ne plus supporter OpenGL pour que tous les développeurs passent a DirectX dans la crainte de perdre une part de marché.
OpenGL est toujours supporté, mais c'est Microsoft qui dicte les règles du jeu, c'est tout.
Donc la base, elle n'as rien a voir la dedans.
Ton jeu qui ne passe pas sous Linux puisqu'il n'as pas été développé pour aurait très bien pu utiliser OpenGL et fonctionner partout, même en 64bits. Donc faut pas jeter la pierre sur Linux de ce coté là faut plutôt voir comment la plupart des éditeurs s'en mettent pleins les poches de plus en plus en fournissant un minimum de contenu. (je fais notamment référence aux clients qui tue le marché de l'occasion et aux DLC qui sont la dernière connerie inventée pour faire payer les gens..)
Bref, j'arrête là pour ce sujet, mais maintenant si tu as un jeu pour Windows, c'est sûr le lancer sur un vrai Windows c'est mieux.
Mais ça aurait été encore mieux si tu avais eu une version Linux native et 64bits.

Pour la virtualisation, je sais pas qui est ton prof, mais bon, n'importe quel système peut être virtualisé, surtout si il est assez récent. Donc si tu as un PC qui tiens la route c'est bon


Depuis un LiveCD, tu peux redimensionner les partitions, pense a défragmenter les NTFS avant sinon ça peut poser quelques pb's.
Si tu veux partitionner depuis Windows: Démarrer → Faire un clic droit sur Ordinateur (Poste de travail sous Xp) → Et choisir "Gérer" → Aller ensuite dans stockage → Gestion des disques, et voilà.

Perso l'installation que je fais a chaque fois:
1 - NTFS de 50% du disque avec Windows 7 64bits
2 - Ext4 de 50% du disque avec Ubuntu 12.04 LTS 64bits
3 - SWAP de 1Go de plus que la RAM du PC

Sinon, t'en fait pas, niveau foutre en l'air un système ou entrer dedans comme ça je sais aussi faire
Une simple LiveUSB et tu rentre dans n'importe quoi

Pour revenir au problème de base, si tu l'as eu sous Windows, même une seule fois, c'est que la SFML contient le bug. (selon une théorie infondée)







Réponse a Laurent (qui a posté quand j'étais en train d'écrire):

C'est normal que le port reste indisponible quelques minutes. Du coup ce qui me paraît louche c'est plutôt ton exemple qui fonctionne : le port devrait tout être autant indisponible.

Pourquoi le port devrait être indisponible alors qu'il n'y a plus aucune application dessus?
Merci

[Laurent]

Un conseil : si vous voulez discuter d'autre chose faites le ailleurs, parce que là, avec les murs de texte que vous postez, peu de gens vont prendre la peine de lire et extraire les parties relatives au vrai problème. Je dis ça aussi pour les gens qui auraient la même question / le même problème, et qui reliraient cette discussion.

Pourquoi le port devrait être indisponible alors qu'il n'y a plus aucune application dessus?

C'est le comportement par défaut des sockets, pour des raisons de fiabilité.
Il y a une bonne explication détaillée ici :
http://stackoverflow.com/questions/3229860/what-is-the-meaning-of-so-reuseaddr-setsockopt-option-linux/3233022#3233022

Et je pense que tu peux en trouver d'autres si nécessaire, avec comme mot-clé "SO_REUSEADDR".

[Crone123]

Je comprends, en fait c'est l'OS qui bloque volontairement le port pour éviter les erreurs en cas de ré-utilisation?

D'après ce que j'ai compris en lisant: Il est possible de passer outre avec SO_REUSEADDR c'est ça?
Donc c'est pas du tout un bug de la SFML :p
Merci

PS: Je pense que je vais essayer de me créer une classe de socket en utilisant les fonctions de Linux directement.
J'ai envie de saisir le fonctionnement exact et exploiter les différentes options possible, bref, bien comprendre comment ça marche avant de faire des conneries, d'autant que j'ai l'ambition d'un projet assez conséquent qui nécessite des socket très stables. Je pourrais sans problèmes utiliser des trucs uniquement Linux puisque mon projet est codé pour un but personnel et pour un serveur Linux en particulier.

[Laurent]

Sinon tu as aussi des bibliothèques dédiées au réseau, très complètes et beaucoup plus sympa à utiliser que l'API de base des sockets. Genre boost.asio par exemple.

[Crone123]

J'avais déjà essayé boost::asio pour voir, mais j'avais du mal de comprendre comment ça marchait.
Et boost est assez gros comme lib, c'est un peu bête de devoir rajouter ça alors que je pourrais utiliser quelque chose de moins lourd, mon programme doit être petit et optimisé...
En fait, c'est aussi pour ça que j'utilise la SFML:
→ Petit, Simple, et sauf les quelques bugs que j'ai au niveau du réseau: Rapide et optimisé.
Et la SFML a aussi comme atout de proposer une doc bien détaillée, claire et simple a comprendre, des tutoriels traduits et un très très bon support en Français.
Je suppose que tu connais 4ian, l'auteur de Game Develop. Avant de me mettre au C++ j'étais le membre le plus actif du forum, et en fait j'ai pris l'habitude d'utiliser GD. Le logiciel était simple, performant (il l'est toujours) et pareil: Le support sur le forum était juste énorme
Le logiciel utilise la SFML, c'est pas un pur hasard non plus que la première bibliothèque que j'ai choisi d'utiliser soit la SFML: J'y retrouve exactement ce que j'avais dans Game Develop, mais en plus poussé. (bon, et on a aussi les avantages d'un langage de programmation très modulable)
Et le justement tout ce que j'ai cité au dessus ça m'as vraiment facilité l'apprentissage de la SFML et du C++. (j'ai commencé a utiliser la SFML 1semaine après avoir commencé a coder en C++, c'est là que j'ai commencé a faire mes premiers petits jeux en C++)
Voilà, et pour finir, ici aussi le support sur le forum est énorme

Pour en revenir a boost, bah, c'est comme OpenGL, ou Qt, rentrer dans le tas, c'est a dire sur un site totalement en anglais sans savoir par où commencer, même en lisant la doc et les tutos bah ça fait perdre du temps, c'est ennuyant, et on avance pas.

Je vais voir ce que ça va donner au niveau des socket natif, peut être que ça sera pire, peut être que ça sera mieux (par rapport a boost).
Bon, par contre, ce qui est natif pour avoir la doc suffit de taper man donc ça aide pas mal, et le linkage est automatique
Je sais que la SFML utilise ces socket natifs aussi, donc je pourrais regarder déjà comment ça fonctionne au niveau de la SFML ça pourra m'aider

Un truc qui m’intéresse: J'ai cru voir sur un site que l'on pouvais depuis les socket natif gérer la priorité de traitement des socket, les mettre en mode urgent. Je ne sais pas ce que ça change exactement, mais peut être que ça peut être une bonne idée d'essayer d'utiliser ça pour un service crucial qui sera le cœur d'un très gros projet
Ou alors c'est une option a ne pas utiliser?
Merci

[Laurent]

Oui je te comprends. Je pense que tu as une bonne stratégie pour progresser, par contre ne te perds pas dans les sockets, il y a beaucoup de choses à savoir et beaucoup de stratégies différentes si tu touches directement au bas niveau. Par contre pour les choses simples, ça ne sera pas beaucoup plus compliqué que SFML.

Un truc qui m’intéresse: J'ai cru voir sur un site que l'on pouvais depuis les socket natif gérer la priorité de traitement des socket, les mettre en mode urgent. Je ne sais pas ce que ça change exactement, mais peut être que ça peut être une bonne idée d'essayer d'utiliser ça pour un service crucial qui sera le cœur d'un très gros projet
Ou alors c'est une option a ne pas utiliser?

Jamais entendu parler d'une telle option. Si elle existe, je ne pense pas que ce soit une chose à regarder. C'est typiquement le genre d'option que l'on utilise uniquement quand on sait très exactement ce qu'on fait.

[Crone123]

Dit moi ce que tu en penses:
http://manpagesfr.free.fr/man/man7/tcp.7.html
Description, 5ème paragraphe. (et 6 pour la fin)
Merci

[Laurent]

Et tu voudrais faire quoi avec ça ?

Quoiqu'il en soit je pense que tu abordes les choses du mauvais côté. Apprends les bases, programme ton truc, et une fois que tu auras un truc fonctionnel qui a un problème (si jamais ça arrive), alors là il sera temps de voir ce genre d'option non conventionnelle.

[Crone123]

Ce qui est sûr c'est que je vais commencer par les bases.

Ensuite, pour ce que j'en ferais avec, je sais pas, peut être rien (sûrement), mais l'option est là, donc comme elle est là je veux juste savoir a quoi elle sert (Avoir une explication en fait )
Après, le fait que ça soit non-conventionnel c'est sûr c'est a éviter.

Je chercherais a quoi ça sert quand j'aurais appris les bases.

Par contre: Les socket natif proposent des connexions locales, sans carte réseau, donc directement d'application a application. Un peu comme ce qui est utilisé pour dbus, pulseaudio, alsa, ou encore xorg, et dans mon cas c'est probable que je cherche a les utiliser puisque j'aurais en fait un daemon sur lequel vont se connecter des clients locaux a la machine. Le daemon supportera aussi des connexions extérieures, mais ça ne sera pas du tout pour la même chose.
A voir
Je vais déjà voir ce qu'il y a de plus standard, on verra plus tard pour le reste
Merci

[Eroy]

La priorité des sockets de ce que je comprend... En gros ça va changer non pas la priorité de la requête car en tcp ça n'existe pas (on ne peut pas garantir l'ordre d'arrivée des données) mais la priorité du processus sur la machine de destination qui va "dans l'idée" interpréter les commandes plus vite et donc acquérir ce message urgent en priorité par rapport aux autres applis qui pourraient utiliser les réseau.
Je dirais un exemple d'utilisation... 2 serveurs, un qui mange de la donnée et un qui sert de superviseur. On passera des données au superviseur via des messages urgents ce qui aura pour effet de légèrement casser le flux de données mais affichera immédiatement les informations pour l'utilisateur.