Reprise du message précédent :
ben oui ...  
mais attention aux timeout des proxy et autres firewall ...
 
PS : et au nombre de sockets & threads ouverts côté serveur si c'est pour bcp d'utilisateurs

aux domaines de sécurité ...

oki je voulais juste confirmation
 
par contre je n'avais pas penser au proxy

une connexion *persistente* sur une *servlet* ? voilà un concept interessant

 
faut que tu fasses un peu de traffic régulièrement pour que les équipement intermédiaires ne cosidèrent pas la connexion comme morte ...

disons que techniquement, on peut imaginer une servlet pour un protocole de streaming par exemple, qui ne serait pas une HTTP servlet.
 
mais bon, à poil sans tomcat quand tu en es à poser des question de ce type, je doute ....

 
j'ai dis une bétise ?  

 
justement c'était ça l'idée, j'ai un serveur reçoit des infos qui remonte d'un reseau propriétaire. Ensuite le serveur doit envoyer l'info à une appli cliente via Internet.

c'est utilisé pour faire de l'ajax ...
 
Jetty (si je me soviens bien) a même fait un truc (qui détourne la spec des servlets) pour être capable d'avoir des "servlets" qui peuvent être mise en pause durant le traitement d'une requête ce qui évite de bouffer un thread.
 
y a aussi de plus en plus de monde qui demande un JSR là dessus ...

ben si ca se fait, mais comme je disais ça consomme un thread et ça fait des requêtes longues => un grand nombre de sockets ouvertes ...

Benou> tu fais peut etre référence à COMET (aussi appelé Reverse Ajax et autres noms ...), héritié des "pushlet".
 
mais ce concept est trop gourmande coté serveur.

ouais, bah oublie les servlets et fais un serveur entièrement proprio.

Ca dépend des besoins, mais ça se fait ...

carrément faire un serveur !!! ça doit etre coton à réaliser un serveur stable, fiable, sécurisé etc...

franchement, ça dépend du nombre d'utilisateurs et du type de connexion (utilisation de proxy http ?).
Si c'est que pour quelques dizaines/centaines d'utilisateurs, un bête tomcat ça tiendra et ce sera moins longs et moins bugable que de recoder un seveur http à la mano.
 
si c'est pour plusieurs milliers d'utilisateurs ou plus, ca demande reflexion ...

pour 10-100 environ

bha t'emmerde pas alors ... une servlet, la mise enplace d'un petit système évenementiel à coup de wait/notify, une gestion d'un timeout toutes les 10s pout faire un "ping" pour que la connexion ne se ferme pas toute seule et roule !  
 
remarque : même pas obligé de te servir d'une applet : si tu veux tu peux t'en sortir à coup de XMLHttpRequest (attention quand même à IE qu igère pas le multipart => besoin de relancer la requête à chaque reception de réponse)
 
 
maintenant, c'est seulement si ton truc doit dialoguer en HTTP ... c'est sûr que si tu as un accès direct à internet et pas de restriction réseau, fait un bête ServerSocket, ça ira encore plus vite

chouette un rébus !

je suis étonné qu'il n'existe pas que je n'ai rien trouver comme solution "simple" pour faire communiqué deux applis à distance via Internet.
Les solutions RMI y réponde peut etre ?  (je n'ai pas encore d'expérience sur les RMI)

bha oui c'est fait pour ça ... mais là c'ets pas du http ...
et ya plein d'autres méthodes (XML/http, soap, xml rpc, corba, etc...).  
 
mais ce que tu veux c'est faire du push depuis un serveur web vers des clients web, c'est plus compliqué parce qu'à la base c'est pas fait pour ça => faut utiliser des "ruses" => c'est (un peu) plus compliqué

hessian/burlap ?

http://www.pushlets.com/
 
(merci pour le terme pushlet que je ne connaissais pas)

avec couple servlet/applet , je pourrait communiquer via RMI entre le serveur et le navigateur, non ?
 
ensuite comme une applet peut exécuter du javascript , l'applet pourrait donc manipuler  via DOM ma page html.
 
mais les "ruses" du push en http , j'ai étudié un peu les solutions, c'est pas top niveau ressource...

oui si tu n'as pas d'équipement intermédiaire qui bloque (comme un proxy HTTP), comme je l'ai déjà dit.
 

c'est pas avec 10 ou 100 connections sumiltanées que tu vas écrouler un serveur.  
Tes threads ils sont en pause => ils bouffent quasi rien. et ca devrait pas non plus écrouler ta RAM ...
 
mais fait des tests plutôt que de rejetter des architectures juste sur des suppositions ... tu seras plus à même de juger de la bonne solution.

all
Ca fait un bon moment que j'ai pas codé en Java-J2EE (facile 1 an voir 2.. ) j'ai donc 2-3 questions..
Quelqu'un utilise t'il Javolution (lib temps réel Java basé sur javax.realtime) ?
Des avis, des conseils par rapport à l'API de base javax.realtime ?
 
Merci

pour ceux qui sont interessé par les solutions push http, un bon petite article (in english) pour faire le point : http://ajaxian.com/archives/reverse-ajax-with-dwr

haaa mais oui, j'avais dja vu ça y'a des années avec du js de sauvage, l'horreur totale ... ça scale?

ça "scale" pas vraiment, ça fini jamais plutot, bref c'est de la ruse comme dit Benou

Ca dépend ... avec un moteur de servlet pas fait pour, ça scale pas des masses ...  
 
Mais y a moyen defaire des trucs qui tiennent la route, ouais. Exemple, msn marche comme ça quand tu le configures pour passer par un proxy http. GoogleTalk dans GMail aussi. Maintenant, je sais pas combien de serveurs ils ont aligné derrière ...

ok

le monsieur te dit qu'il est sur un protocole proprio justement, donc il est déjà à la bite et au couteau, d'où l'idée de ne pas foutre tomcat entre la bite et le couteau.

les sockets inet, tu connais ?

ben non ...
relis :  
 

 
Son serveur reçoit des infos d'un reseau proprio. Ensuite il doit les diffuser à des clients (webs d'après ce que j'ai compris bien qu'il n'ait jamais confirmé), et là il est libre de la façon de faire.

bah il ouvre une socket par client sur des applets et en voiture gertrude.

oui, si y a pas de proxy http à passer ...

il ouvre une connection socks, c'est fait pour
 
nan, parce que les trucs tordu à base de boucles de délais en javascript qui va chercher du XML sur HTTP quand il existe des solutions parfaitement adaptées, je commence à saturer.

  faut un proxy socks pour ça ... souvent t'as qu'un proxy http (genre en entreprise)

c'est pas ça ...
c'ets pas du pooling, au contraire c'est justement pour l'éviter.
 
le principe c'est de laisser une connexion ouverte pour que le serveur ait un canal direct pour envoyer des données au client dès qu'il en a besoin.
C'est juste ouvrir un canal de communication via du HTTP ...

ah ouais, je vois le genre, on utilise le même genre de conneries pour le tracking de lecture des mails, c'est encore plus détourner le truc.

hein