Michel Claveau, résurectionné d'outre-bombe informatique
Bonjour !
L'idée d'un accès par un navigateur est intéressante.
Toutefois HTTP est un métaprotocole, basé sur TCP/IP. Du coup, ton argument s'inverse : puisqu'il y a TCP/IP, pourquoi y ajouter une couche HTTP, qui, en plus va nécessiter un formatage du contenu des trames, pour les transformer en requêtes HTTP.
A noter que, pour plus de rapidité, UDP serait encore plus adapté, et aussi facile à implémenter que TCP.
Mais l'argument du navigateur reste valable.
@-salutations -- Michel Claveau
Bonjour !
L'idée d'un accès par un navigateur est intéressante.
Toutefois HTTP est un métaprotocole, basé sur TCP/IP. Du coup, ton argument
s'inverse : puisqu'il y a TCP/IP, pourquoi y ajouter une couche HTTP, qui,
en plus va nécessiter un formatage du contenu des trames, pour les
transformer en requêtes HTTP.
A noter que, pour plus de rapidité, UDP serait encore plus adapté, et aussi
facile à implémenter que TCP.
L'idée d'un accès par un navigateur est intéressante.
Toutefois HTTP est un métaprotocole, basé sur TCP/IP. Du coup, ton argument s'inverse : puisqu'il y a TCP/IP, pourquoi y ajouter une couche HTTP, qui, en plus va nécessiter un formatage du contenu des trames, pour les transformer en requêtes HTTP.
A noter que, pour plus de rapidité, UDP serait encore plus adapté, et aussi facile à implémenter que TCP.
Mais l'argument du navigateur reste valable.
@-salutations -- Michel Claveau
Xavier Combelle
Michel Claveau, résurectionné d'outre-bombe informatique wrote:
Toutefois HTTP est un métaprotocole, basé sur TCP/IP. Du coup, ton argument s'inverse : puisqu'il y a TCP/IP, pourquoi y ajouter une couche HTTP, qui, en plus va nécessiter un formatage du contenu des trames, pour les transformer en requêtes HTTP. Pour moi un métaprotocole reste un protocole.
De même que TCP est un protocole sur IP, que IP est un protocole le plus souvent basé sur éthernet, la plus part des protocole rajoutent quelques fonctionnalités sur un autre protocole.
Le choix du protocole doit être un compromis entre fonctionnalité désirées et disponibilité du protocole. (par exemple, je préfère faire du HTTP que du RMI)
La fonctionnalité principale qui est implémenté par HTTP est le formalisme question-réponse, qui est particulièrement adapté à ce problème.
De part mes propres observations, la plus part des applications client/serveur ne font pas de push serveur vers client. Dans ce cadre, le protocole HTTP correspond particulièrement bien au besoin.
A noter que, pour plus de rapidité, UDP serait encore plus adapté, et aussi facile à implémenter que TCP. Personnellement, je trouve que, avec Python, HTTP est plus facile à
implémenter (par exemple, on n'a pas besoin de gérer les longueurs de trame, de définir le format des requêtes ou celui des réponses ....) Concernant la rapidité, j'ai quelques doutes, a moins que tu ne parles du temps de réaction en cas de non réponse.
Mais l'argument du navigateur reste valable. Disons que c'est un plus indéniable, mais que ce n'est pas le seul
(cf ci-dessus)
Xavier
Michel Claveau, résurectionné d'outre-bombe informatique wrote:
Toutefois HTTP est un métaprotocole, basé sur TCP/IP. Du coup, ton argument
s'inverse : puisqu'il y a TCP/IP, pourquoi y ajouter une couche HTTP, qui,
en plus va nécessiter un formatage du contenu des trames, pour les
transformer en requêtes HTTP.
Pour moi un métaprotocole reste un protocole.
De même que TCP est un protocole sur IP, que IP est un protocole le plus
souvent basé sur éthernet, la plus part des protocole rajoutent quelques
fonctionnalités sur un autre protocole.
Le choix du protocole doit être un compromis entre fonctionnalité
désirées et disponibilité du protocole. (par exemple, je préfère faire
du HTTP que du RMI)
La fonctionnalité principale qui est implémenté par HTTP est le
formalisme question-réponse, qui est particulièrement adapté à ce problème.
De part mes propres observations, la plus part des applications
client/serveur ne font pas de push serveur vers client. Dans ce cadre,
le protocole HTTP correspond particulièrement bien au besoin.
A noter que, pour plus de rapidité, UDP serait encore plus adapté, et aussi
facile à implémenter que TCP.
Personnellement, je trouve que, avec Python, HTTP est plus facile à
implémenter (par exemple, on n'a pas besoin de gérer les longueurs de
trame, de définir le format des requêtes ou celui des réponses ....)
Concernant la rapidité, j'ai quelques doutes, a moins que tu ne parles
du temps de réaction en cas de non réponse.
Mais l'argument du navigateur reste valable.
Disons que c'est un plus indéniable, mais que ce n'est pas le seul
Michel Claveau, résurectionné d'outre-bombe informatique wrote:
Toutefois HTTP est un métaprotocole, basé sur TCP/IP. Du coup, ton argument s'inverse : puisqu'il y a TCP/IP, pourquoi y ajouter une couche HTTP, qui, en plus va nécessiter un formatage du contenu des trames, pour les transformer en requêtes HTTP. Pour moi un métaprotocole reste un protocole.
De même que TCP est un protocole sur IP, que IP est un protocole le plus souvent basé sur éthernet, la plus part des protocole rajoutent quelques fonctionnalités sur un autre protocole.
Le choix du protocole doit être un compromis entre fonctionnalité désirées et disponibilité du protocole. (par exemple, je préfère faire du HTTP que du RMI)
La fonctionnalité principale qui est implémenté par HTTP est le formalisme question-réponse, qui est particulièrement adapté à ce problème.
De part mes propres observations, la plus part des applications client/serveur ne font pas de push serveur vers client. Dans ce cadre, le protocole HTTP correspond particulièrement bien au besoin.
A noter que, pour plus de rapidité, UDP serait encore plus adapté, et aussi facile à implémenter que TCP. Personnellement, je trouve que, avec Python, HTTP est plus facile à
implémenter (par exemple, on n'a pas besoin de gérer les longueurs de trame, de définir le format des requêtes ou celui des réponses ....) Concernant la rapidité, j'ai quelques doutes, a moins que tu ne parles du temps de réaction en cas de non réponse.
Mais l'argument du navigateur reste valable. Disons que c'est un plus indéniable, mais que ce n'est pas le seul
(cf ci-dessus)
Xavier
Michel Claveau, résurectionné d'outre-bombe informatique
Bonsoir !
Voilà un exemple de serveur TCP/IP, qui écoute le port 8888, et qui répond à une trame commençant par "TEST".
Il m'étonnerait qu'un serveur HTTP soit plus simple à implémenter...
import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind((socket.gethostbyname(socket.gethostname()),8888)) while 1: s.listen(1) conn, adr = s.accept() if conn.recv(16)[:4]=="TEST": conn.send("Je suis en fonctionnement.") conn.close()
Bonsoir !
Voilà un exemple de serveur TCP/IP, qui écoute le port 8888, et qui répond
à une trame commençant par "TEST".
Il m'étonnerait qu'un serveur HTTP soit plus simple à implémenter...
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind((socket.gethostbyname(socket.gethostname()),8888))
while 1:
s.listen(1)
conn, adr = s.accept()
if conn.recv(16)[:4]=="TEST":
conn.send("Je suis en fonctionnement.")
conn.close()
Voilà un exemple de serveur TCP/IP, qui écoute le port 8888, et qui répond à une trame commençant par "TEST".
Il m'étonnerait qu'un serveur HTTP soit plus simple à implémenter...
import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind((socket.gethostbyname(socket.gethostname()),8888)) while 1: s.listen(1) conn, adr = s.accept() if conn.recv(16)[:4]=="TEST": conn.send("Je suis en fonctionnement.") conn.close()
Michel Claveau, résurectionné d'outre-bombe informatique
Re
Et, pour la vitesse, j'ai fait un test sur mon réseau. Résultat : 1000 requêtes avec réponse, en 6 secondes (mesuré côté client).
-- Michel Claveau
Re
Et, pour la vitesse, j'ai fait un test sur mon réseau. Résultat : 1000
requêtes avec réponse, en 6 secondes (mesuré côté client).
Michel Claveau, résurectionné d'outre-bombe informatique wrote:
Bonsoir !
Voilà un exemple de serveur TCP/IP, qui écoute le port 8888, et qui répond à une trame commençant par "TEST".
Il m'étonnerait qu'un serveur HTTP soit plus simple à implémenter...
plus facile, je sais pas, mais aussi facilement, je crois.
import BaseHTTPServer
class MyHTTPRequestHandler(BaseHTTPServer.BaseHTTPRequestHandler): def do_GET(self): reponse = "Je suis en fonctionnement" self.send_response(200) self.send_header("Content-type", "text/html") self.end_headers() print >>self.wfile, reponse def log_request(self,code='-', size='-'): pass BaseHTTPServer.test(MyHTTPRequestHandler, BaseHTTPServer.HTTPServer)
Xavier Combelle
Michel Claveau, résurectionné d'outre-bombe informatique wrote:
Re
Et, pour la vitesse, j'ai fait un test sur mon réseau. Résultat : 1000 requêtes avec réponse, en 6 secondes (mesuré côté client).
En soit, un temps n'est pas significatif, ca dépend de la configuration. Il faudrait comparer nos deux programmes de test. Voici le mien. Juste pour info, les 1000 connexions chez moi tournent en moins de 3 secondes (une fois que j'ai viré les log du serveur, sinon 8 secondes). Il me semble que la performance reste néanmoins un critère secondaire, par rapport à la simplicité du code, et de la compatibilité avec les navigateurs.
Concernant la simplicité du code, la simplicité de nos serveur est comparable, mais quelle est celles de ton client? (j'évite de tricher en disant que mozilla = 0 lignes de code)
# -*- coding: iso-8859-15 -*- import urllib2 from time import time
t1 = time()
for i in range(1000): f = urllib2.urlopen('http://10.111.16.10:8000/') x= f.read() if x<>"Je suis en fonctionnementn": raise "problème d'accès au serveur", x t2 = time()
print t2 - t1
Au vu du résultat, la simplicité des deux codes étant identiques, je préfère ma version qui permet d'avoir plus de souplesse et qui implémente un protocole standard.
Michel Claveau, résurectionné d'outre-bombe informatique wrote:
Re
Et, pour la vitesse, j'ai fait un test sur mon réseau. Résultat : 1000
requêtes avec réponse, en 6 secondes (mesuré côté client).
re-@-salutations
En soit, un temps n'est pas significatif, ca dépend de la configuration.
Il faudrait comparer nos deux programmes de test.
Voici le mien. Juste pour info, les 1000 connexions chez moi tournent en
moins de 3 secondes (une fois que j'ai viré les log du serveur, sinon 8
secondes).
Il me semble que la performance reste néanmoins un critère secondaire,
par rapport à la simplicité du code, et de la compatibilité avec les
navigateurs.
Concernant la simplicité du code, la simplicité de nos serveur est
comparable, mais quelle est celles de ton client? (j'évite de tricher en
disant que mozilla = 0 lignes de code)
# -*- coding: iso-8859-15 -*-
import urllib2
from time import time
t1 = time()
for i in range(1000):
f = urllib2.urlopen('http://10.111.16.10:8000/')
x= f.read()
if x<>"Je suis en fonctionnementn":
raise "problème d'accès au serveur", x
t2 = time()
print t2 - t1
Au vu du résultat, la simplicité des deux codes étant identiques, je
préfère ma version qui permet d'avoir plus de souplesse et qui
implémente un protocole standard.
Michel Claveau, résurectionné d'outre-bombe informatique wrote:
Re
Et, pour la vitesse, j'ai fait un test sur mon réseau. Résultat : 1000 requêtes avec réponse, en 6 secondes (mesuré côté client).
En soit, un temps n'est pas significatif, ca dépend de la configuration. Il faudrait comparer nos deux programmes de test. Voici le mien. Juste pour info, les 1000 connexions chez moi tournent en moins de 3 secondes (une fois que j'ai viré les log du serveur, sinon 8 secondes). Il me semble que la performance reste néanmoins un critère secondaire, par rapport à la simplicité du code, et de la compatibilité avec les navigateurs.
Concernant la simplicité du code, la simplicité de nos serveur est comparable, mais quelle est celles de ton client? (j'évite de tricher en disant que mozilla = 0 lignes de code)
# -*- coding: iso-8859-15 -*- import urllib2 from time import time
t1 = time()
for i in range(1000): f = urllib2.urlopen('http://10.111.16.10:8000/') x= f.read() if x<>"Je suis en fonctionnementn": raise "problème d'accès au serveur", x t2 = time()
print t2 - t1
Au vu du résultat, la simplicité des deux codes étant identiques, je préfère ma version qui permet d'avoir plus de souplesse et qui implémente un protocole standard.
