Sockets?

[Bourinho]

Bonjour à tous...

Je m'apprête à poser une question où les mots utilisés ne seront probablement pas les bons

En effet, je m'intéresse à des types de connexion un peu particulier... qui passent par les sockets dans le but d'avoir une connexion continue dans les deux sens. (en espérant ne pas être complétement à côté de la plaque!)

L'application que je souhaiterais en faire serait telle que ces connexions ne seront pas utilisés pour transférer des gros fichiers mais juste des petits paquets de données de temps à autres (des paquets ne dépassant pas le Ko vraisemblablement). Le point fort de ces "sockets" (d'après ce que j'ai compris), c'est que le client comme le serveur peut prendre l'initiative pour l'envoi de données...

Je me demandais comment cela était vécu côté serveur... parce que je souhaiterais que plusieurs clients puissent disposer de ces connexions mais que ces connexions ne soit pas partagées...c'est à dire que j'aurais des données pour le client C1 qui ne seront pas pour le client C2 et inversement...sachant que j'aimerais proposer un tel service à plus de 1000 clients...

Est ce que cela demande une infrastructure et un équipement dément ou est ce que tout serveur dédié peut s'acquitter de ce type de tâche??? Quel est le facteur limitant au niveau hardware dans ce type d'utilisation???

Par avance merci et pardon pour le vocabulaire certainement approximatif!

[rportal]

Voici une piste pour des sockets en java script: http://dev.dschini.org/socketjs/

Note: nécessite flash

Du côté serveur, il te faudra un process dédié pour gérer ton application. Un serveur web ne fera pas forcement l'affaire, il faudra surement chercher autre chose... Un serveur d'application serait mieux (J2EE ou .NET).

[Jeromnimo]

Bonjour Bourinho,

à priori, lorsque que tu mets en place une communication basée sur des sockets, tu auras des processus en écoute sur un socket donné. Je m'explique :

Au niveau de ton serveur, tu seras en écoute sur le même socket pour tout le monde, mais tu sauras au moment de la communication qui "parle" au serveur.

Par contre dans l'autre sens, je ne vois pas trop comment tu veux te débrouiller ? tu comptes demander aux clients d'installer une appli chez eux ? Ou alors pour que le serveur joigne un client il faudra forcément que le serveur initie la communication ???

Tu aurais un peu plus d'infos (si elle ne sont pas confidentielles ;-) sur ce que tu aimerais faire ?

Un peu d'infos sur les sockets : http://www.commentcamarche.net/sockets/sockintro.php3

EDIT : grillé par rportal... :-/

Modifié 5 Septembre 2006 par Jeromnimo

[destroyedlolo]

L'utilisation des sockets est surtout utile pour faire communiquer 2 applications ensembles, mais comme tu dis que des petits paquets de données de temps à autres, un web service est peut etre plus indique.

L'avantage de la socket par rapport au webservice est que c'est plus rapide et que tu as un mode connecte. Mais les inconvegnants sont assez nombreux :

• assez complexe a programmer generalement
  
• c'est du bas niveau, donc tu dois tout gerer (securite, protocole, eventuellement encodage, ...)
  
• si tu as des grand moment de calme, il faut mettre en place une sort de ping ou de heart beat sinon la connection va tombe en timeout
  
• si tes clients ou toi devez passer par des firewall ... ben faudra les configurer pour autoriser les ports.
  
• ...
  

Avec les Web service, c'est pas connecte, mais tu as l'avantage de te baser sur l'architecture HTTP, ce qui fait que tu n'as plus a te soucier du bas niveau.

Apres, ca depend vraiment de qui discute avec quoi et pourquoi faire

[Bourinho]

Merci pour vos réponses...

Je vais donc tâcher d'être plus précis.

Du côté serveur, il te faudra un process dédié pour gérer ton application. Un serveur web ne fera pas forcement l'affaire, il faudra surement chercher autre chose... Un serveur d'application serait mieux (J2EE ou .NET).

Je vais m'informer sur ce point...étant donné que la différence ne me saute pas aux yeux...

tu comptes demander aux clients d'installer une appli chez eux ?

Je compte bien mettre en place une application chez chacun des clients (pour l'instant, je me dirige vers le VB.NET)

Avec les Web service, c'est pas connecte, mais tu as l'avantage de te baser sur l'architecture HTTP, ce qui fait que tu n'as plus a te soucier du bas niveau.

C'est un peu ce sur quoi je m'informais récemment... mais je ne voyais pas comment avec ce procédé donner "l'initiative au serveur". En clair, je ne vois pas comment je peux forcer l'application en VB.NET à faire une sorte de rafraichissement... Apres reflexion, je crois pouvoir me passer de cela...

-----------

En fait, ce que je souhaite faire, c'est envoyé entre une dixaine et une centaine de paquets de 1ko par jour du serveur vers le client (équipé d'une application en conséquence) et aussi dans l'autre sens (client vers serveur)...mais l'une des contraintes est que je veux que le client comme le serveur puisse avoir l'initiative d'envoyer ces paquets de données.

Par exemple, le serveur d'application reçoit une demande d'envoi de données de la part d'un serveur web, je veux que le serveur d'application puisse envoyer un paquet de données en conséquence et que le client le recoive directement mais je souhaite aussi qu'il reste à l'écoute si jamais un client veut envoyer un paquet de données.

En espérant avoir été à peu près clair...

D'après rportal, il faudra un serveur d'application...pourra t'il communiquer avec un serveur web??? (a priori, je ne vois pas pourquoi ce ne serait pas possible...)

Merci pour toutes vos réponses!

[Edit]Apres reflexion, je pense me tourner vers le traditionnel protocole HTTP(S) comme on me l'a souffle, ce sera beaucoup moins contraignant... Mais je souhaitais avoir plus d'infos sur cette possibilite afin d'avoir des raisons precises de l'ecarter... Merci au Hub![/Edit]

Modifié 6 Septembre 2006 par Bourinho