*EP001370048A1* EP 1 370 048 A1 (19) (11) EP 1 370 048 A1 (12) DEMANDE DE BREVET EUROPEEN. (43) Date de publication: 10.12.2003 Bulletin 2003/50



Documents pareils
TEPZZ 6Z85Z5A T EP A2 (19) (11) EP A2 (12) DEMANDE DE BREVET EUROPEEN

TEPZZ A_T EP A1 (19) (11) EP A1 (12) DEMANDE DE BREVET EUROPEEN. (51) Int Cl.: G07F 7/08 ( ) G06K 19/077 (2006.

EP A2 (19) (11) EP A2 (12) DEMANDE DE BREVET EUROPEEN. (43) Date de publication: Bulletin 2009/22

(51) Int Cl.: H04L 29/06 ( ) G06F 21/55 ( )

(51) Int Cl.: B23P 19/00 ( ) B23P 19/04 ( ) F01L 1/053 ( )

EP A1 (19) (11) EP A1 (12) DEMANDE DE BREVET EUROPEEN. (43) Date de publication: Bulletin 2009/25

EP A1 (19) (11) EP A1 (12) DEMANDE DE BREVET EUROPEEN. (43) Date de publication: Bulletin 2012/50

TEPZZ A_T EP A1 (19) (11) EP A1 (12) DEMANDE DE BREVET EUROPEEN

*EP A1* EP A1 (19) (11) EP A1 (12) DEMANDE DE BREVET EUROPEEN. (43) Date de publication: Bulletin 2003/37

EP A1 (19) (11) EP A1 (12) DEMANDE DE BREVET EUROPEEN. (51) Int Cl.: H04L 29/06 ( ) H04L 29/12 ( )

TEPZZ 5 5 _9A_T EP A1 (19) (11) EP A1 (12) DEMANDE DE BREVET EUROPEEN

EP A1 (19) (11) EP A1 (12) DEMANDE DE BREVET EUROPEEN. (51) Int Cl.: H04L 12/58 ( )

Rank Xerox (UK) Business Services

EP A1 (19) (11) EP A1 (12) DEMANDE DE BREVET EUROPEEN. (43) Date de publication: Bulletin 2011/40

EP A1 (19) (11) EP A1 (12) DEMANDE DE BREVET EUROPEEN. (43) Date de publication: Bulletin 2011/26

*EP A1* EP A1 (19) (11) EP A1 (12) DEMANDE DE BREVET EUROPEEN. (43) Date de publication: Bulletin 2000/39

TEPZZ 8758_8A_T EP A1 (19) (11) EP A1 (12) DEMANDE DE BREVET EUROPEEN. (51) Int Cl.: A61K 33/00 ( ) A61P 25/06 (2006.

". TY convertisseur statique, et des condensateurs de filtrage.

EP A1 (19) (11) EP A1 (12) DEMANDE DE BREVET EUROPEEN. (43) Date de publication: Bulletin 2011/09

GENERALITES. COURS TCP/IP Niveau 1

TEPZZ 65 Z4A_T EP A1 (19) (11) EP A1 (12) DEMANDE DE BREVET EUROPEEN. (51) Int Cl.: B01D 3/00 ( )

Paiements transfrontaliers

îundesdruokerei Berlin

Principes de DHCP. Le mécanisme de délivrance d'une adresse IP à un client DHCP s'effectue en 4 étapes : COMMUTATEUR 1. DHCP DISCOVER 2.

TEPZZ 699Z A_T EP A1 (19) (11) EP A1 (12) DEMANDE DE BREVET EUROPEEN. (51) Int Cl.: H04W 12/06 ( ) H04L 29/06 (2006.

EP A1 (19) (11) EP A1 (12) DEMANDE DE BREVET EUROPEEN. (43) Date de publication: Bulletin 2011/21

Bundesdruckerei Berlin

Jouve, 18, rue Saint-Denis, PARIS

DEMANDE DE BREVET EUROPEEN. PLASSERAUD 84, rue d'amsterdam, F Paris (FR)

3) Demandeur: FIVES-CAIL BABCOCK, Société anonyme 7 rue Montallvet F Parts Cedex 08 (FR)

1 Résolution de nom Introduction à la résolution de noms Le système DNS Les types de requêtes DNS...

RÈGLEMENTS INTÉRIEURS ET DE PROCÉDURE

Firewall. Souvent les routeurs incluent une fonction firewall qui permet une première sécurité pour le réseau.

Informations techniques et questions

Innover à l'ère du numérique : ramener l'europe sur la bonne voie Présentation de J.M. Barroso,

ANNEX 1 ANNEXE RÈGLEMENT DÉLÉGUÉ (UE) N /.. DE LA COMMISSION

Je suis sous procédure Dublin qu est-ce que cela signifie?

Internet - Outils. Nicolas Delestre. À partir des cours Outils réseaux de Paul Tavernier et Nicolas Prunier

COMMENT PAYEZ-VOUS? COMMENT VOUDRIEZ-VOUS PAYER?

B o u r s e d e m o b i l i t é B E E p o u r l e s d é p a r t s e n

EP A1 (19) (11) EP A1 (12) DEMANDE DE BREVET EUROPEEN. (43) Date de publication: Bulletin 2010/05

Présentation du modèle OSI(Open Systems Interconnection)

Serveur FTP. 20 décembre. Windows Server 2008R2

Guide SEPA Paramétrage Experts Solutions SAGE depuis 24 ans

Dynamic Host Configuration Protocol

Fax: Soumission des offres et des demandes de participation par voie électronique (URL):

0 Numéro de publication: Al 0 DEMANDE DE BREVET EUROPEEN

Windows Internet Name Service (WINS)

LE RESEAU GLOBAL INTERNET

Linux sécurité des réseaux

II/ Le modèle OSI II.1/ Présentation du modèle OSI(Open Systems Interconnection)

Notice d installation des cartes 3360 et 3365

Délégation Côte d Azur Formation Geslab 203 module dépenses 1

Installation et configuration d un serveur DHCP (Windows server 2008 R2)

Plan du Travail. 2014/2015 Cours TIC - 1ère année MI 30

Numéro de publication: Al. int. Cl.5: H01H 9/54, H01H 71/12. Inventeur: Pion-noux, uerara. Inventeur: Morel, Robert

Arkoon Security Appliances Fast 360

DHCP et NAT. Cyril Rabat Master 2 ASR - Info Architecture des réseaux d entreprise

TAGREROUT Seyf Allah TMRIM

Oléane VPN : Les nouvelles fonctions de gestion de réseaux. Orange Business Services

SIP. Sommaire. Internet Multimédia

Sécurité des réseaux Firewalls

Europâisches Patentamt European Patent Office Office européen des brevets. Numéro de publication: A1 DEMANDE DE BREVET EUROPEEN

SIP A. Aoun - La Visioconférence SIP - 1

VoIP et "NAT" VoIP et "NAT" 1/ La Traduction d'adresse réseau. 1/ La traduction d'adresse réseau. 1/ La traduction d'adresse réseau

TR2 : Technologies de l'internet. Chapitre VI. NAT statique et dynamique Overloading (PAT) Overlapping, port Forwarding Serveur Proxy, DMZ

J ai demandé l asile dans l Union européenne quel pays sera responsable de l analyse de ma demande?

Notes explicatives concernant le formulaire d opposition

Le filtrage de niveau IP

«clustering» et «load balancing» avec Zope et ZEO

Guide de connexion à. RENAULT SA et PSA PEUGEOT CITROËN. via ENX

Réseau : Interconnexion de réseaux, routage et application de règles de filtrage.

1 La visualisation des logs au CNES

Présentation du système DNS

Numéro de publication: Al. Int. CIA H03K 17/12, H03K 17/08. Demandeur: FERRAZ Societe Anonyme

Le protocole ARP (Address Resolution Protocol) Résolution d adresses et autoconfiguration. Les protocoles ARP, RARP, TFTP, BOOTP, DHCP

TD 2 Chapitre 4 : Support des Services et Serveurs. Objectifs : Maîtriser l'exploitation des tables de routage dynamique.

ARRANGEMENT ET PROTOCOLE DE MADRID CONCERNANT L ENREGISTREMENT INTERNATIONAL DES MARQUES DEMANDE D ENREGISTREMENT INTERNATIONAL RELEVANT

TD n o 8 - Domain Name System (DNS)

Alexis Lechervy Université de Caen. M1 Informatique. Réseaux. Filtrage. Bureau S3-203

Fonctionnement et mise en place d un reverse proxy sécurisé avec Apache. Dimitri ségard 8 mai 2011

Soumission des offres et des demandes de participation par voie électronique (URL):

Administration des ressources informatiques

Proxy et reverse proxy. Serveurs mandataires et relais inverses

ETI/Domo. Français. ETI-Domo Config FR

(51) Int Cl.: B60R 25/00 ( )

La VoIP et ToIP. - Les constructeurs de réseaux : Anciens : Alcatel, Ericsson, Nortel, Siemens, Lucent, NEC Nouveaux venus : NetCentrex, Cirpack

192 Office européen des brevets DEMANDE DE BREVET EUROPEEN

SYSTEME DE GESTION DES ENERGIES EWTS EMBEDDED WIRELESS TELEMETRY SYSTEM

COMITÉ ADMINISTRATIF ET JURIDIQUE. Quarante-huitième session Genève, 20 et 21 octobre 2003

1/ 12 BE001 23/01/ Numéro BDA: Formulaire standard 2 - FR Location de machines à café et fourniture de leurs consommables.

Le rôle Serveur NPS et Protection d accès réseau

SECURIDAY 2012 Pro Edition

Sécurité GNU/Linux. Iptables : passerelle

[ Sécurisation des canaux de communication

Le commerce de détail en Europe : la diversité des tissus commerciaux

Protocoles réseaux. Abréviation de Binary Digit. C'est la plus petite unité d'information (0, 1).

FACILITER LES COMMUNICATIONS. Le gestionnaire de réseau VPN global de Saima Sistemas

1/ 14 BE001 4/9/ Numéro BDA: Formulaire standard 2 - FR Acquisition et mise en place d une solution de Business Intelligence

Configuration d'un Réseau Privé Virtuel (RPV ) communément appelé VPN

Transcription:

(19) Europäisches Patentamt European Patent Office Office européen des brevets *EP001370048A1* (11) EP 1 370 048 A1 (12) DEMANDE DE BREVET EUROPEEN (43) Date de publication: 10.12.2003 Bulletin 2003/50 (51) Int Cl. 7 : H04L 29/06, G06F 9/50 (21) Numéro de dépôt: 03291321.2 (22) Date de dépôt: 03.06.2003 (84) Etats contractants désignés: AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR Etats d extension désignés: AL LT LV MK (30) Priorité: 06.06.2002 FR 0206961 (71) Demandeur: ALCATEL 75008 Paris (FR) (72) Inventeurs: Marce, Olivier 91300 Massy (FR) Drago, Carlo 75014 Paris (FR) Clevy, Laurent 28000 Chartres (FR) Le Moigne, Olivier Ottawa, ON, K2B 5K8 (CA) Bereski, Philippe 91390 Morsang sur Orge (FR) Cartier, Jean-Francois 44119 Treillieres (FR) (74) Mandataire: Chaffraix, Sylvain et al Compagnie Financière Alcatel Département de Propriété Industrielle, 5, rue Noel Pons 92734 Nanterre Cedex (FR) (54) Application des réseaux actifs pour la répartition de charge au sein d une pluralité de serveurs de service (57) L'invention concerne un équipement de réseau (E 1,E 2,E 3 ) pour la transmission de paquets de données, certains de ces paquets de données contenant des requêtes de service, ledit service étant mis en oeuvre par une pluralité de serveurs (S 1,S 2,S 3 ), caractérisé en ce qu'il dispose de moyens pour recevoir des paquets de données contenant ou référençant du code exécutable et des moyens pour décider de la transmission de ces paquets de données à un autre équipement de réseau ou de l'exécution de ce code exécutable qui est prévu pour répartir les requêtes de service parmi la pluralité de serveurs. EP 1 370 048 A1 Printed by Jouve, 75001 PARIS (FR)

1 EP 1 370 048 A1 2 Description [0001] La présente invention concerne la répartition de charge au sein d'un ensemble de serveurs, mettant en oeuvre un même service. L'invention s'applique particulièrement bien aux réseaux actifs. [0002] Différentes solutions de l'état de la technique sont par exemple présentées dans l'article «Load Balancing your Web site - Practical approaches for distributing HTTP traffic» de Ralf S. Engelschall, publié en 1998 dans «New architect». Cet article est par exemple disponible sur Internet, à l'adresse suivante : http://www.webtechniques.com/archives/ 1998/05/engelschall/ [0003] La figure 1 illustre une première solution de l'état de la technique. Dans l'article ci-dessus, cette première solution est intitulée «The reverse proxy approach». [0004] Un équipement, non représenté, transmet une requête de service R. Cette requête est véhiculée par le réseau N. Le service requis est implémenté par plusieurs serveurs S 1,S 2 et S 3. En amont de ces serveurs, il a été prévu un dispositif D chargé de la répartition de charge. C'est ce dispositif qui est appelé «reverse proxy» dans l'article de Ralf S. Engelschall. [0005] À la réception de la requête de service R, ce dispositif va décider de la transmettre vers le serveur S 1 (requête R 1 ), vers le serveur S 2 (requête R 2 ) ou bien vers le serveur S 3 (requête R 3 ). Ce choix dans le serveur destinataire de la requête peut dépendre de règles simples : par exemple, le dispositif D peut transmettre les requêtes de service successivement à chaque serveur, dans l'ordre. [0006] Cette approche présente un principal inconvénient qui est l'absence de flexibilité en terme de topologie. En effet, pour qu'un ensemble de serveurs S 1,S 2, S 3 puisse bénéficier de la fonction de répartition de charge, il est nécessaire que ces serveurs soient situés de telle manière que toutes les requêtes qui leur sont destinées passent par le dispositif D. [0007] La figure 2 illustre une seconde solution de l'état de la technique. [0008] Dans l'article mentionné précédemment, cette solution est intitulée «The DNS approach». [0009] L'équipement E désire transmettre une requête de service. Classiquement, afin de connaître l'adresse IP (Internet Protocol) du serveur implémentant ce service, il interroge un serveur de noms de domaines DNS (pour «Domain Name Server») via un message m 1. En réponse, le serveur de noms de domaines DNS lui retourne un message m 2 contenant cette adresse. Selon cette solution, le serveur de noms de domaines peut être modifié et prévu pour renvoyer l'adresse d'un serveur différent en fonction d'une règle de répartition de charge. Ainsi, en fonction de la réponse de ce serveur de noms de domaine, l'équipement de réseau E va transmettre une requête R 1 vers un serveur S 1, une requête R 2 vers un serveur S 2 ou bien une requête R 3 5 10 15 20 25 30 35 40 45 50 55 vers un serveur S 3. [0010] Cette solution permet de réaliser la répartition de charge entre des serveurs situés à différents endroits du réseau, mais soufre d'autres inconvénients. Le premier d'entre eux est le fait qu'une fois qu'une première interrogation du serveur de noms de domaines DNS est effectuée, la réponse est mémorisée (cachée) par l'équipement de réseau E. La requête de service suivante ne fera pas forcément appel au serveur de noms de domaines, et dans ce cas, elle sera dirigée vers le même serveur sans qu'aucun contrôle de l'état de sa charge ne soit effectué. [0011] D'autre part, cette solution repose sur l'hypothèse que l'interrogation du serveur de noms de domaines DNS est effectuée par le client et qu'elle est directement adressée au système de répartition de charge. Cette hypothèse n'est pas valide dans toutes les configurations, notamment lorsqu'une passerelle de type «pare-feu» (ou firewall en langue anglaise) émet les interrogations à destination de l'extérieur en lieu et place du client. [0012] Une troisième approche est divulguée par le brevet américain US 6 370 584. Selon cette solution, les différents serveurs fournissant le même service effectuent la répartition entre eux, c'est-à-dire sans l'aide d'un dispositif extérieur. Une telle solution n'est pas satisfaisante dès lors que ces serveurs peuvent être distants : il en résulte alors des communications supplémentaires entre les serveurs pour re-router les requêtes de services qui d'une part peuvent être préjudiciable pour la charge du réseau de télécommunication, mais aussi peuvent engendrer des retards supplémentaires dans le traitement des requêtes de service. [0013] La présente invention a pour but de palier ces différents problèmes posés par les solutions de l'état de la technique. [0014] Pour ce faire, l'invention a pour premier objet un équipement de réseau pour la transmission de paquets de données, certains de ces paquets de données contenant des requêtes de service, le service étant mis en oeuvre par une pluralité de serveurs. Selon l'invention, cet équipement de réseau se caractérise en ce qu'il dispose de moyens pour recevoir des paquets de données contenant ou référençant du code exécutable et des moyens pour décider de la transmission de ces paquets de données à un autre équipement de réseau ou de l'exécution du code exécutable, ce code exécutable étant prévu pour répartir les requêtes de service parmi la pluralité de serveurs. [0015] L'invention a pour second objet un dispositif de gestion associé à une pluralité de serveurs rattachés à un réseau, chacun de ces serveurs mettant en oeuvre un même service. Ce dispositif de gestion se caractérise en ce qu'il dispose de moyens pour transmettre à des équipements de réseau, des codes exécutables ou des références à des codes exécutables, prévus pour répartir les requêtes parmi la pluralité de serveurs. [0016] L'invention a pour troisième objet un procédé 2

3 EP 1 370 048 A1 4 pour répartir la charge au sein d'une pluralité de serveurs rattachés à un réseau, mettant en oeuvre un service. Ce procédé se caractérise en ce qu'il comporte une étape de transmission de paquets de données contenant ou référençant du code exécutable prévu pour être exécuté par des équipements du réseau et pour répartir les requêtes de service parmi la pluralité de serveurs. [0017] Selon une mise en oeuvre de l'invention, la pluralité de serveurs est répartie en plusieurs groupes, chaque groupe étant rattaché à un équipement différent du réseau. [0018] Outre la résolution des problèmes des solutions de l'état de la technique, l'invention permet de surcroît de gérer aisément la situation dans laquelle les serveurs ne seraient pas rattachés à un unique équipement du réseau. [0019] L'invention et ses avantages apparaîtront de façon plus claire dans la description d'une mise en oeuvre de l'invention, qui va suivre, en liaison avec les figures annexées. [0020] Les figures 1 et 2, déjà commentées, illustrent deux solutions de l'état de la technique. [0021] La figure 3 représente le fonctionnement du mécanisme de répartition de charge selon l'invention. [0022] La figure 4 schématise la mise en place de ce mécanisme. [0023] Sur la figure 3, l'équipement de réseau E 1 reçoit une requête de service. Cet équipement de réseau est par exemple un routeur IP, et le réseau N auquel il appartient est un réseau de données de technologie IP (Internet Protocol). [0024] Cet équipement de réseau E 1 possède un code exécutable prévu pour répartir cette requête de service parmi deux équipements de réseau «en sortie», E 2 et E 3. [0025] Cette répartition peut par exemple être conforme aux ressources des serveurs associés aux chemins correspondant aux équipements de réseau E 1 et E 2. Si, par exemple, chaque serveur de l'ensemble des serveurs S 1,S 2 et S 3 dispose de ressources équivalentes, la ressource globale associée au chemin allant vers l'équipement de réseau E 2 sera 2 fois plus élevée que celle associée au chemin allant vers l'équipement de réseau E 3. [0026] Une règle simple de répartition pourra alors être de faire une répartition statistique du nombre de requête vers les deux équipements E 2 et E 3, avec un poids 2 pour l'équipement E 2 et un poids 1 pour l'équipement E 3. Autrement dit, chaque requête de service parvenant à l'équipement E 1 aura une probabilité 2/3 d'être transmise, selon une requête R 12 vers l'équipement E 2 et une probabilité de 1/3 d'être transmise, selon une requête R 13 vers l'équipement E 3. [0027] L'équipement de réseau E 2 possède deux serveurs S 1,S 2 qui lui sont rattachés. De la même façon que l'équipement de réseau E 1, il dispose d'un code exécutable prévu pour répartir les requêtes de service qui lui parviennent. 5 10 15 20 25 30 35 40 45 50 55 [0028] À titre d'exemple, si les deux serveurs S 1 et S 2 disposent de ressources équivalentes, le code exécutable exécuté par l'équipement E 2 peut simplement répartir les requêtes de service entrantes R 12 de façon équiprobable, soit vers le serveur S 1 en une requête R 1, soit vers le serveur S 3 en une requête R 2. [0029] Enfin, l'équipement de réseau E 3 transmettra normalement les requêtes de services entrantes R 13 à destination du serveur S 3, aucune répartition de charge n'ayant lieu à cet endroit. [0030] L'exemple de règle de répartition mise en oeuvre par le code exécutable, qui a été donnée, l'a été à titre non limitatif. D'autres heuristiques sont bien évidemment possibles, de même que des algorithmes plus évolués. [0031] La figure 4 montre une façon dont les codes exécutables peuvent être transmis aux équipements de réseau. [0032] Selon une mise en oeuvre de l'invention, ces exécutables sont transmis par un dispositif de gestion M. La transmission peut consister : À transmettre un paquet de données contenant le code exécutable, Ou à transmettre un paquet de données contenant une référence de ce code exécutable. Le code exécutable lui-même peut être mémorisé dans les équipements de réseau eux-mêmes ou bien dans un serveur de codes exécutables, non représenté sur la figure. [0033] Ces deux mécanismes répondent aux principes généraux de la technologie connue sur le nom de «réseau actif». [0034] La référence peut par exemple être un identificateur permettant de déterminer un code exécutable unique sur un serveur de codes exécutables, ou sur l'équipement de réseau lui-même. [0035] Dans le cas où le paquet de données contient le code exécutable, celui-ci peut par exemple être prévu pour s'exécuter sur une plate-forme logicielle de type CORBA (Common Object Request Broker Architecture) tel que spécifiée par l'omg (Object Management Group). Ceci permet au code exécutable d'interagir de façon plus simple avec les différents composants logiciels préalablement installés sur l'équipement de réseau. [0036] Le dispositif de gestion M est préférentiellement prévu pour transmettre des codes exécutables différents à plusieurs équipements de réseau : par exemple, il transmettra un code exécutable c 1 à l'équipement E 1, un code exécutable c 2 à un équipement E 2 et un code exécutable c 3 à un équipement E 3. [0037] On peut ainsi facilement modifier les règles de répartition de charge, en transmettant à l'équipement de réseau adéquat, un nouveau code exécutable. [0038] Par exemple, si le serveur S 1 devient indisponible ou trop chargée, on peut transmettre à l'équipe- 3

5 EP 1 370 048 A1 6 ment de réseau E 2 un nouveau code exécutable prévu pour transmettre toutes les requêtes de service vers le serveur S 2. [0039] Étant donné que dans ce cas, la répartition des ressources est faite entre le groupe de serveurs rattaché à l'équipement E 2 et celui rattaché à l'équipement E 3, un nouveau code exécutable peut aussi être transmis à l'équipement E 1. [0040] Ce nouveau code actif peut par exemple être prévu pour transmettre les requêtes de service arrivantes, de façon équiprobable vers les équipements E 2 et E 3. [0041] Un autre avantage est que le dispositif de gestion M peut être étroitement associé aux serveurs S 1, S 2,S 3. Par exemple, il peut régulièrement sonder les serveurs ou obtenir des informations de ceux-ci, afin de déterminer leur degré de charge. En fonction de ces informations, il peut déterminer de nouvelles règles de répartition à appliquer et déterminer les codes exécutables à transmettre aux équipements adéquats. [0042] Par ailleurs, il devient possible, grâce à l'invention, de supprimer ou d'ajouter des serveurs. Par exemple, si un nouveau serveur mettant en oeuvre le service est rattaché à l'équipement E 3, le dispositif de gestion M pourra transmettre un nouveau code exécutable aux équipements de réseau E 1 et E 3. [0043] Il est également possible de prévoir plusieurs dispositifs de gestion. Chacun d'entre eux peut alors gérer une partie des serveurs disponibles. Une répartition possible consiste à ce que chaque dispositif de gestion gère les serveurs qui lui sont topologiquement proches, par exemple dans le même sous-réseau. Dans ce cas, chaque dispositif de gestion est responsable de l'envoie du code exécutable à l'équipement de réseau le plus proche, de façon à répartir la charge selon la politique choisie. [0044] Selon une mise en oeuvre de l'invention, le ou les dispositif(s) de gestion M peut ou peuvent être localisé(s) sur un des serveurs S 1,S 2,S 3. Ce peut par exemple être un module logiciel exécuté sur ce serveur. 5 10 15 20 25 30 35 40 2. Dispositif de gestion (M) associé à une pluralité de serveurs (S 1,S 2,S 3 ) rattachés à un réseau (N), chacun desdits serveurs mettant en oeuvre un même service, caractérisé en ce qu'il dispose de moyens pour transmettre à des équipements de réseau (E 1,E 2,E 3 ) des codes exécutables ou des références de codes exécutables (c 1,c 2,c 3 ), prévus pour répartir les requêtes parmi ladite pluralité de serveurs. 3. Procédé pour répartir la charge au sein d'une pluralité de serveurs (S 1,S 2,S 3 ) rattachés à un réseau (N), mettant en oeuvre un service, caractérisé en ce qu'il comporte une étape de transmission de paquets de données contenant ou référençant du code exécutable (c 1,c 2,c 3 ) prévu pour être exécuté par des équipements (E 1,E 2,E 3 ) dudit réseau et pour répartir les requêtes de service parmi ladite pluralité de serveurs. 4. Procédé selon la revendication précédente, dans lequel ladite pluralité de serveurs est répartie en plusieurs groupes, chaque groupe étant rattaché à un équipement différent dudit réseau. Revendications 1. Équipement de réseau (E 1,E 2,E 3 ) pour la transmission de paquets de données, certains de ces paquets de données contenant des requêtes de service, ledit service étant mis en oeuvre par une pluralité de serveurs (S 1,S 2,S 3 ), caractérisé en ce qu'il dispose de moyens pour recevoir des paquets de données contenant ou référençant du code exécutable et des moyens pour décider de la transmission desdits paquets de données à un autre équipement de réseau ou de l'exécution dudit code exécutable, ledit code exécutable étant prévu pour répartir lesdites requêtes de service parmi ladite pluralité de serveurs. 45 50 55 4

EP 1 370 048 A1 5

EP 1 370 048 A1 6

EP 1 370 048 A1 7

EP 1 370 048 A1 8