Discussion :

[Squalthor]

Bonjour,

J'ai découvert il y a peu, et avec joie, les websockets ! Je suis très intérressé par cette technologie qui pour moi est l'avenir du web. Mais malgré les différents tutos que j'ai pût avoir sur le net, y compris sur developpez.com, je n'ai aucune idée de comment mettre tout ça en place...

Apparement, pour mes besoins (et mon plaisir) il me faudrait mettre en place un serveur js.

Mais comme je suis dans le flou le plus total je me pose certaines questions.
Comment gérer l'affichage proprement, accède à une base de donnée mysql, écrire dans des fichiers textes ?

Dois-je faire tout ça en javascript ou dois-je accorder une place au php, et si oui, comment ?

Voilà, si vous pouviez éclairer ma lanterne je vous en serais reconnaissant.

Merci !

Cordialement, Squal.

[SylvainPV]

Des serveurs websocket, on peut en faire facilement avec Node.js oui. Il existe de nombreux modules pour faciliter la gestion. Mais on peut tout à fait mélanger requêtes HTTP classiques et Websockets avec le même serveur, donc l'appellation "serveur websocket" n'est pas forcément justifiée. Aussi, plein d'autres serveurs implémentent les WebSockets, dans d'autres langages (Java, PHP, .NET)

Comment gérer l'affichage proprement, accède à une base de donnée mysql, écrire dans des fichiers textes ?

Comme tu le ferais avec des requêtes HTTP classiques. Websocket n'est que le protocole d'échange, ça n'a pas de conséquences pour le reste.

Je te conseille l'excellent socket.io, qui fournit de nombreux fallbacks de manière transparente aux navigateurs ne supportant pas les WS.

[Squalthor]

Bonjour SylvainPV !

J'ai écris ce sujet à l'arrache, je m'en excuse...
Je te remercie de prendre le temps de m'expliquer.
Afin de comprendre j'ai suivi cet excellent tuto , malheureusement maintenant je bloque.

Effectivement, serveur websocket n'est pas correcte, je suis conscient que c'est un serveur javascript qu'il me faut coder pour gerer les connexions, mais je n'ai pas encore la notion de serveur, tout ça me parait flou.

Cordialement, Squal

[sekaijin]

non il n'est absolument pas necessaire d'avoir un serveur js pour coder les websockets.
c# http://divyen.wordpress.com/2012/06/...sharp-dot-net/
php http://code.google.com/p/phpwebsocket/
http://www.phpzend.net/a/zendframewo...-a-simple-chat
c http://warmcat.com/_wp/2010/11/01/li...-library-in-c/
c++ http://winsockwebsocket.codeplex.com/
java http://jwebsocket.org/
javascript http://martinsikora.com/nodejs-and-w...-chat-tutorial


http://www.websocket.org/

enfin commonjs qui vise à normaliser les api js côté serveur propose de l'implémenté au dessus de IO/B

A+JYT

[ABCIWEB]

Bonjour,
J'ai découvert il y a peu, et avec joie, les websockets ! Je suis très intérressé par cette technologie qui pour moi est l'avenir du web...
Apparement, pour mes besoins (et mon plaisir) il me faudrait mettre en place un serveur js

C'est l'avenir du web uniquement pour les sites qui ont besoin de cette technologie, à savoir changement en temps réel de l'affichage visiteur en fonction de l'actualisation des données du serveur. Pratiquement en dehors des chats et des jeux, je vois pas grand intérêt. Actuellement pour des petits besoins et faire l'équivalent (c'est juste un peu moins en temps réel sinon on sature le serveur de requêtes) on utilise des requêtes ajax. C'est moins optimisé mais ça à l'avantage d'être beaucoup plus portable à contrario d'un serveur websocket qui est spécifique.
Un peu comme toi je suis ce sujet depuis quelques temps par curiosité. Mais comme ces technologies sont plus en phase de développement que réellement matures j'attends qu'un standard se dégage avant d'approfondir le sujet. En plus il faudrait investir dans un serveur websocket uniquement pour faire des tests grandeur nature... Je ne sais pas tes besoins réels mais si c'est pour expérimenter et faire des petits tests tu peux utiliser Nodester qui est un serveur Node.js.

[sekaijin]

effectivement la phase websocket au w3c est "dev"
http://dev.w3.org/html5/websockets/
quant au protocole qui lui est normalisé par IETF il en est à "draft"
http://datatracker.ietf.org/doc/rfc6455/?include_text=1

A+JYT

[Squalthor]

Bonjour,

Je vous remercie pour votre contribution.
Je pense que les websockets sont l'avenir du web, et je ne vous cacherais pas que le côté temps réel m'intérresse grandement, par curiosité mais également par "besoins".

Je projete de coder un site de chat basé sur les websockets, j'ai déjà tenté brièvement l'expérience via ajax et jquery mais il faut bien avouer que c'est bien moins pratique et amusant.

De plus j'aimerais apprendre à maitriser leur fonctionnement pour, par la suite , développer si possible un jeu sur navigateur en temps réel, c'est mon délire...

Il semblerait, si j'ai bien compris, que coder un serveur en javascript permette d'exécuter sur javascript côté client sans passer par un fichier js (client) trop volumineux et donc éviter également que le client ai accès aux sources du serveur, je me trompe ?

Le fait que ce soit en phase "dev" m'intérresse d'autant plus, ça pourrait peut-être me permettre de me démarquer...

P.s: je suis autodidacte, avec un faible niveau scolaire (voir intellectuel) et c'est parce que j'ai du mal que je viens vous solliciter.

Bonnes fêtes.

Cordialement, Martin.

[SylvainPV]

Il semblerait, si j'ai bien compris, que coder un serveur en javascript permette d'exécuter sur javascript côté client sans passer par un fichier js (client) trop volumineux et donc éviter également que le client ai accès aux sources du serveur, je me trompe ?

Euh non rien à voir

Le code côté serveur reste côté serveur, et le code client côté client. Tu ne peux pas exécuter du code serveur côté client, ça n'a pas de sens. Et ton client n'aura jamais accès à tes sources serveur, puisque par définition elles sont côté serveur.

La seule particularité à coder une partie côté serveur en Javascript est que tu peux partager des bouts de code côté client et côté serveur. Quand je dis partager, c'est que tu peux copier-coller le code (où le charger de chaque côté à partir du même fichier source), pas que le client aura accès à du code serveur sans l'exécuter comme par magie. Le partage de code client/serveur, c'est un peu l'objectif à long terme de CommonJS (http://www.commonjs.org/). Mais dans les faits je n'ai jamais vu un seul bon exemple de partage de code client/serveur. Donc selon moi l'intérêt est moindre. Ceci dit Node.js est un excellent serveur pour des petites tâches avec des hauts besoins en performance (du style webservices sur base NoSQL très sollicités)

C'est l'avenir du web uniquement pour les sites qui ont besoin de cette technologie, à savoir changement en temps réel de l'affichage visiteur en fonction de l'actualisation des données du serveur.

Tout à fait d'accord, Websocket est un protocole intéressant mais n'est pas l'avenir du Web, car ne correspond qu'à une petite portion des usages. Les Server Sent Events et le polling sont d'autres solutions similaires plus intéressantes pour certains usages.

[Squalthor]

Merci de me détromper, j'ai fais ma flemme j'ai pas tâtonné par moi même...
Je commence à y voir un peu plus clair, grâce à vos contributions, je vais me pencher plus sérieusement sur ce type de développement.

Merci

[Kaamo]

Attention cependant. Qui dit Websocket dit VPS ou serveur dédié, out les mutualisés !
C'est peut-être anodin comme remarque mais il ne faut pas oublier ça car niveau budget, ce n'est pas le même du tout

[Squalthor]

Bonjour,

Effectivement, c'est très important de le préciser, avoir un vps ou serveur dédié permet de gérer les ports et lancer les scripts. Pour ma part j'ai un dédié, que je souhaite quand même rentabilisé !

Histoire de m'y mettre j'ai rien trouvé de mieux que d'analyser le code source de ce tuto comme un autodidacte.

Bizarrement j'y arrive et au final je m'y retrouve mieux qu'avec un serveur en js, enfin pour le moment du moins !