Support réseau pour les applications.
nouknouk
typiquement:
- j'ai compris qu'on avait accès au minimum aux requêtes HTTP.
- peut-on ouvrir une connexion cliente TCP et utiliser la socket comme
on l'entend ?
- si oui, peut-on désactiver l'algorithme de Nagle en cas de besoins
'temps-réel' pour une communication TCP (ie. le flag 'TCP_NODELAY'
dans toute socket TCP qui se respecte).
- peut-on ouvrir une socket TCP 'serveur' (ie. écouter un port et
attendre la connexion d'autres clients) ?
- a-t-on accès aux sockets UDP ?
Merci d'avance.
Cedric BAIL
> Je voudrais connaître l'étendue des possibilités en matière de réseau,
> typiquement:
>
> - j'ai compris qu'on avait accès au minimum aux requêtes HTTP.
Oui, via l'API ecore_con_url.
> - peut-on ouvrir une connexion cliente TCP et utiliser la socket comme
> on l'entend ?
Il y a aussi l'API ecore_con, qui permet de faire des clients/serveur
en TCP et UDP.
> - si oui, peut-on désactiver l'algorithme de Nagle en cas de besoins
> 'temps-réel' pour une communication TCP (ie. le flag 'TCP_NODELAY'
> dans toute socket TCP qui se respecte).
Non.
> - peut-on ouvrir une socket TCP 'serveur' (ie. écouter un port et
> attendre la connexion d'autres clients) ?
Oui.
> - a-t-on accès aux sockets UDP ?
Oui.
Il faut noter que Elixir sait gerer deux types de donnees en entree,
soit des chaines de characteres soit un Eet_Data (c'est a dire une
structure C serialise) qui seront converti dans des objets js
correspondant. Par contre, il ne peut pour l'instant que emettre des
chaines de charactere. Il y a actuellement des limitations dans Eet
qui doivent etre fixer pour permettre l'envoie direct d'objet
serialise depuis le Javascript.
L'interet d'utiliser Eet, c'est de pouvoir diminuer la charge des
serveurs, car convertir une structure Eet en structure C est bien plus
rapide que de parser/manipuler du XML ou du JSON. Ca devrait permettre
de diminuer les besoins materiels cotes serveur.
--
Cedric BAIL
nouknouk
On 19 nov, 14:10, Cedric BAIL <moa.blueb...@gmail.com> wrote:
> > - si oui, peut-on désactiver l'algorithme de Nagle en cas de besoins
> > 'temps-réel' pour une communication TCP (ie. le flag 'TCP_NODELAY'
> > dans toute socket TCP qui se respecte).
>
> Non.
>
réel se satisfont largement d'un canal TCP pour peu qu'on puisse
désactiver la mise en cache des paquets.
Ca veut concrètement dire que poru du 'temps-réel' on va être obligé
de passer par de l'UDP, quitte à devoir se re-coder à la main une
gestion complète de perte / réémission de paquets, etc...
Une chance pour voir cet possibilité apparaître dans le SDK un jour ou
l'autre ?
Autre question: si on veut faire des applis complètement P2P (donc
sans serveur de jeu intermédiaire), encore faut-il que le routeur
accepte les connexions entrantes UDP et TCP, car si j'ouvre une socket
TCP 'serveur' mais que la box ADSL me bloque les connexions entrantes,
ça va pas servir à grand chose.
Y a-t-il quelque chose de prévu de ce côté là (genre uPnP automatique
dès qu'on écoute sur un port) ?
Merci.
Cedric BAIL
> On 19 nov, 14:10, Cedric BAIL <moa.blueb...@gmail.com> wrote:
>> > - si oui, peut-on désactiver l'algorithme de Nagle en cas de besoins
>> > 'temps-réel' pour une communication TCP (ie. le flag 'TCP_NODELAY'
>> > dans toute socket TCP qui se respecte).
>>
>> Non.
>>
>
> Ca par contre, c'est vraiment dommage. Beaucoup de petit jeux temps
> réel se satisfont largement d'un canal TCP pour peu qu'on puisse
> désactiver la mise en cache des paquets.
>
> Ca veut concrètement dire que poru du 'temps-réel' on va être obligé
> de passer par de l'UDP, quitte à devoir se re-coder à la main une
> gestion complète de perte / réémission de paquets, etc...
>
> Une chance pour voir cet possibilité apparaître dans le SDK un jour ou
> l'autre ?
Oui, il suffit d'integrer ca proprement a l'API d'ecore. En ajoutant
peut-etre un type ECORE_CON_REMOTE_TCP_NODELAY a Ecore_Con_Type et le
code pour le gerer dans ecore_con
(http://trac.enlightenment.org/e/browser/trunk/ecore/src/lib/ecore_con,
regarder Ecore_Con.h et ecore_con.c). Je n'aurais pas le temps de m'en
occuper, mais si quelqu'un fait un patch et l'envoi sur la ml de
Enlightenment, je pense que ca ne posera pas de probleme pour
l'integrer.
> Autre question: si on veut faire des applis complètement P2P (donc
> sans serveur de jeu intermédiaire), encore faut-il que le routeur
> accepte les connexions entrantes UDP et TCP, car si j'ouvre une socket
> TCP 'serveur' mais que la box ADSL me bloque les connexions entrantes,
> ça va pas servir à grand chose.
Les boitiers HD n'ont uniquement acces que aux reseaux IPv6. Chaque
boitier HD a une vrai IPv6 qui lui permet d'acceder sans limitation à
Internet. Pas de probleme de nat, pas de probleme de port a ouvrir. Il
est meme possible de faire une differenciation entre PC et Freebox,
car elles ne sont pas dans le meme sous reseau IPv6.
> Y a-t-il quelque chose de prévu de ce côté là (genre uPnP automatique
> dès qu'on écoute sur un port) ?
Pas besoin :-)
--
Cedric BAIL
nouknouk
soucis :-)
On 19 nov, 14:58, Cedric BAIL <moa.blueb...@gmail.com> wrote:
> Oui, il suffit d'integrer ca proprement a l'API d'ecore. En ajoutant
> peut-etre un type ECORE_CON_REMOTE_TCP_NODELAY a Ecore_Con_Type et le
> code pour le gerer dans ecore_con
> (http://trac.enlightenment.org/e/browser/trunk/ecore/src/lib/ecore_con,
> regarder Ecore_Con.h et ecore_con.c). Je n'aurais pas le temps de m'en
> occuper, mais si quelqu'un fait un patch et l'envoi sur la ml de
> Enlightenment, je pense que ca ne posera pas de probleme pour
> l'integrer.
pour les feebox en est une autre, ai-je tort ?
D'une façon plus globale, et pour mieux cerner les choses ; les
intervenants ici (comme toi, Cédric, Vincent, ... y en a-t-il
d'autres ?) sont-ils bien les représentants Free ou simplement des
passionnés éclairés qui connaissent à la fois les EFL et la freebox ?
En d'autres termes - et désolé si je mets un peu (brutalement) les
pieds dans le plat, c'est juste pour clarifier les choses -, quel
'crédit' puis-je accorder a un promesse comme "ca ne posera pas de
comprendre qui fait quoi, qui sait quoi et qui a le pouvoir de décider
quoi.
Merci d'avance.
Cedric BAIL
> On 19 nov, 14:58, Cedric BAIL <moa.blueb...@gmail.com> wrote:
>> Oui, il suffit d'integrer ca proprement a l'API d'ecore. En ajoutant
>> peut-etre un type ECORE_CON_REMOTE_TCP_NODELAY a Ecore_Con_Type et le
>> code pour le gerer dans ecore_con
>> (http://trac.enlightenment.org/e/browser/trunk/ecore/src/lib/ecore_con,
>> regarder Ecore_Con.h et ecore_con.c). Je n'aurais pas le temps de m'en
>> occuper, mais si quelqu'un fait un patch et l'envoi sur la ml de
>> Enlightenment, je pense que ca ne posera pas de probleme pour
>> l'integrer.
>
> L'intégrer à eCore est une chose ; qu'il soit repris dans une update
> pour les feebox en est une autre, ai-je tort ?
Au prochain firmware :-) Je suis plus que de maniere active le svn des
EFL et le firmware integre un snapshot recent. Actuellement, c'est un
snapshot d'avant l'ajout du support des deformations sur les objets
(le truc qui permet de faire ce qu'on voit sur cette page
http://www.phoronix.com/scan.php?page=news_item&px=NzcxNQ).
> D'une façon plus globale, et pour mieux cerner les choses ; les
> intervenants ici (comme toi, Cédric, Vincent, ... y en a-t-il
> d'autres ?) sont-ils bien les représentants Free ou simplement des
> passionnés éclairés qui connaissent à la fois les EFL et la freebox ?
Alors, je suis le seul a travailler chez Free sur les EFL. Les autres
ne sont que des passionnes qui participent, souvent depuis longtemps,
au projet enlightenment.
> En d'autres termes - et désolé si je mets un peu (brutalement) les
> pieds dans le plat, c'est juste pour clarifier les choses -, quel
> 'crédit' puis-je accorder a un promesse comme "ca ne posera pas de
> probleme pour l'integrer".
Je m'occupe de l'integration des EFL dans le firmware de la Freebox,
tant que ca ne touche que les EFL et la Freebox, je sais de quoi je
parle :-)
> Encore une fois, ce n'est pas du troll ; c'est juste pour mieux
> comprendre qui fait quoi, qui sait quoi et qui a le pouvoir de décider
> quoi.
Pas de souci, c'est un forum public et il est normal de clarifier un
peu qui fait quoi.
--
Cedric BAIL
Vincent Barrier
Vincent Barrier
Cedric BAIL
> J'essaye de tester les exemples et je ne comprend pas celui ci
> : ecore_con_url je reste sur status : 0
> Ca veut dire qu'il n'arrive pas à charger l'url : http://portail.free.fr ?
C'est exactement ca. C'est parce que pour l'instant l'acces reseau est
bloque sur la Freebox.
--
Cedric BAIL
Vincent Barrier
Cedric BAIL
> 2009/11/19 nouknouk <alexandre...@gmail.com>:
>> On 19 nov, 14:10, Cedric BAIL <moa.blueb...@gmail.com> wrote:
>>> > - si oui, peut-on désactiver l'algorithme de Nagle en cas de besoins
>>> > 'temps-réel' pour une communication TCP (ie. le flag 'TCP_NODELAY'
>>> > dans toute socket TCP qui se respecte).
>>>
>>> Non.
>>>
>>
>> Ca par contre, c'est vraiment dommage. Beaucoup de petit jeux temps
>> réel se satisfont largement d'un canal TCP pour peu qu'on puisse
>> désactiver la mise en cache des paquets.
>>
>> Ca veut concrètement dire que poru du 'temps-réel' on va être obligé
>> de passer par de l'UDP, quitte à devoir se re-coder à la main une
>> gestion complète de perte / réémission de paquets, etc...
>>
>> Une chance pour voir cet possibilité apparaître dans le SDK un jour ou
>> l'autre ?
>
> Oui, il suffit d'integrer ca proprement a l'API d'ecore. En ajoutant
> peut-etre un type ECORE_CON_REMOTE_TCP_NODELAY a Ecore_Con_Type et le
> code pour le gerer dans ecore_con
> (http://trac.enlightenment.org/e/browser/trunk/ecore/src/lib/ecore_con,
> regarder Ecore_Con.h et ecore_con.c). Je n'aurais pas le temps de m'en
> occuper, mais si quelqu'un fait un patch et l'envoi sur la ml de
> Enlightenment, je pense que ca ne posera pas de probleme pour
> l'integrer.
Ca sera ECORE_CON_REMOTE_NODELAY (
http://trac.enlightenment.org/e/changeset/43818/trunk ).
--
Cedric BAIL
nouknouk
> Ca sera ECORE_CON_REMOTE_NODELAY (http://trac.enlightenment.org/e/changeset/43818/trunk).
>
> Cedric BAIL
Magnifique !
Merci !
kiki
On 19 nov, 22:51, Cedric BAIL <moa.blueb...@gmail.com> wrote:
>
> C'est exactement ca. C'est parce que pour l'instant l'acces reseau est
> bloque sur la Freebox.
>
> --
> Cedric BAIL
D'avance merci.
Cedric BAIL
Robert Auger
Je comprends que l'accès réseau est bloqué en ce moment sur la
freebox, mais est-il bloqué vers l'extérieur uniquement, vers
l'intérieur aussi ou les deux ?
C'est-à-dire :
- pas de possibilité de connexion à un site web comme www.free.fr à
partir d'un jeux freebox ?
- pas de possibilité de connexion entre un ordinateur connecté à la
freebox ADSL et un jeu tournant sur la freebox HD ?
Merci pour vos lumières.
On 21 nov, 12:09, Cedric BAIL <moa.blueb...@gmail.com> wrote:
> 2009/11/21 kiki <christian.boiteas...@gmail.com>:
Cedric BAIL
> Je comprends que l'accès réseau est bloqué en ce moment sur la
> freebox, mais est-il bloqué vers l'extérieur uniquement, vers
> l'intérieur aussi ou les deux ?
> C'est-à-dire :
> - pas de possibilité de connexion à un site web comme www.free.fr à
> partir d'un jeux freebox ?
> - pas de possibilité de connexion entre un ordinateur connecté à la
> freebox ADSL et un jeu tournant sur la freebox HD ?
Actuellement, les applications elixir n'ont juste pas acces au reseau.
De plus a terme, elles n'auront jamais que acces au reseaux IPv6.
--
Cedric BAIL
LEE Patrick
On 25 nov, 17:53, Cedric BAIL <moa.blueb...@gmail.com> wrote:
> 2009/11/25 Robert Auger <bobyg...@gmail.com>:
Tu veux dire par la que les applications ne pourront pas acceder aux
services IPV4
sur le net ?
Merci pour ta réponse.
>
> --
> Cedric BAIL
Cedric BAIL
Cédric Schieli
2009/11/25 LEE Patrick <patric...@gmail.com>:
> On 25 nov, 17:53, Cedric BAIL <moa.blueb...@gmail.com> wrote:
[...]
Oui.>> Actuellement, les applications elixir n'ont juste pas acces au reseau.
>> De plus a terme, elles n'auront jamais que acces au reseaux IPv6.
>
> Salut,
>
> Tu veux dire par la que les applications ne pourront pas acceder aux
> services IPV4 sur le net ?
Ce qui pourrait être sympa, pour permettre au moins des accès HTTP vers des sites web IPv4, ce serait la mise à disposition d'un proxy HTTP IPv6/IPv4. Pour taper sur des webservices, c'est quand même plus facile ;-)