FR2829330A1 - Procede de demande de reception du resultat d'execution d'une fonction a distance a une date predeterminee - Google Patents
Procede de demande de reception du resultat d'execution d'une fonction a distance a une date predeterminee Download PDFInfo
- Publication number
- FR2829330A1 FR2829330A1 FR0111330A FR0111330A FR2829330A1 FR 2829330 A1 FR2829330 A1 FR 2829330A1 FR 0111330 A FR0111330 A FR 0111330A FR 0111330 A FR0111330 A FR 0111330A FR 2829330 A1 FR2829330 A1 FR 2829330A1
- Authority
- FR
- France
- Prior art keywords
- execution
- result
- date
- function
- reception
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/62—Establishing a time schedule for servicing the requests
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/133—Protocols for remote procedure calls [RPC]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer And Data Communications (AREA)
- Information Transfer Between Computers (AREA)
Abstract
Ce procédé d'exécution d'une fonction par un système informatique serveur sur réception d'une requête d'exécution en provenance d'un système informatique client, dans un réseau de communication, comporte les étapes suivantes :- extraction (E600) de la requête d'exécution d'au moins une date de réception par le client d'un premier résultat d'exécution de la fonction;- prédiction (E620) d'un débit de transfert sur le réseau sensiblement à la date de réception;- détermination (E620) d'une date d'envoi du premier résultat vers le client, la date d'envoi étant déterminée en fonction de la date de réception et du débit de transfert;- exécution (E655) de la fonction et obtention du premier résultat;- envoi du premier résultat au client sensiblement à la date d'envoi.
Description
eVou encore un procédé de turbodécodage selon la revendication 7.
La présente invention a trait au domaine des réseaux de communication informatique dans lesquels des programmes informatiques sont
exécutés à distance.
L'invention concerne plus particulièrement, d'une part, un procédé de demande de réception, à une date prédéterminée, du résultat d'exécution d'une fonction exécutable à distance, et d'autre part un procédé d'exécution de
cette fonction permettant de fournir le résultat d'exécution à cette date.
L'invention concerne également des dispositifs aptes à mettre en
_uvre les procédés précités.
Dans le cadre de la présente invention, la notion de "date" s'entend d'un instant déterminé dans le temps et est exprimée par exemple sous la forme: jour de la semaine, quantième dans le mois, et heure - ou bien sous la forme d'un délai par rapport à une date ou un moment donnés dans ie
temps.
Dans les réseaux de communication informatique sont connectés de nombreux systèmes d'ordinateurs, tels que des ordinateurs personnels, et des périphériques de traitement, tels que des imprimantes, unités de stockage, moyens d'acquisition, de traitement ou de stockage d'images ou autres types
de documents.
La présente invention s'applique plus particulièrement aux réseaux de communication qui définissent un protocole de communication permettant aux ordinateurs et périphériques d'échanger des requêtes et des acquittements à ces requêtes; Ces réseaux utilisent le principe connu sous le terme "client serveur" pour l'échange d'informations entre des systèmes d'ordinateurs, désignés ici par le terme général "station". Selon ce principe, une station dite "cliente" émet une requête d'exécution d'une fonction vers une station dite
"serveur" qui exécute la fonction et retourne le résultat à la station cliente.
Les station clientes peuvent être des systèmes d'utilisateurs, alors que les stations serveurs peuvent étre des serveurs réseaux dédiés à exécuter des fonctions. Cependant chacune des stations du réseau considéré peuvent
être aussi "clientes" ou "serveurs".
De manière générale, il s'écoule un temps plus ou moins long entre le moment o un utilisateur demande, depuis une station cliente, à exécuter une fonction sur une station serveur, et le moment o il reçoit le
résultat d'exécution de cette fonction.
Ce temps qui comprend en particulier le temps d'exécution de la fonction sur le système informatique serveur et le temps de transfert du résultat d'exécution depuis le serveur vers le client, dépend notamment: -de la charge de travail du serveur informatique au moment de l'exécution de la fonction; et - de l'encombrement et de la bande passante du réseau de communication. Lorsque ce temps est long, il peut être source de perte de temps pour l'utilisateur qui doit attendre le résultat d'exécution de la fonction pour pouvoir l'utiliser. D'autre part, plus le temps de transfert est long et plus le risque est grand de voir survenir une panne réseau pendant ce transfert, ce qui obligerait l'utilisateur à reformuler ultérieurement une demande d'exécution de
la même fonction.
Par ailleurs, plus le temps de transfert est grand et plus le temps de connexion au serveur est important, ce qui augmente le coût financier de la connexion au réscau eVou au serveur, lorsque ce coût est comptabilisé en
fonction de la durée de la connexion.
L'invention vise à pallier à ces inconvénients en proposant selon un premier aspect, un procédé de demande, par un système informatique client, d'au moins un résultat d'exécution d'une fonction exécutable sur un système informatique serveur, dans un réseau de communication, caractérisé en ce qu'il comporte les étapes suivantes: - détermination d'au moins une date de réception d'un premier résultat d'exécution; - envoi d'une requête d'exécution à destination du serveur, la requête d'exécution comportant la date de réception, en vue de recevoir le
premier résultat sensiblement à la date de réception.
Corrélativement, I'invention vise également un dispositif de demande d'au moins un résultat d'exécution d'une fonction exécutable sur un système informatique serveur, le dispositif pouvant être intégré dans un système informatique client, dans un réscau de communication, caractérisé en ce qu'il comporte: - des moyens de détermination d'au moins une date de réception d'un premier résultat d'exécution; - des moyens d'envoi d'une requête d'exécution à destination du serveur, la requête d'exécution comportant la date de réception, en vue de recevoir le premier résultat sensiblement à la date de réception; et
-des moyens de réception du premier résultat.
Le procédé et le dispositif exposés ci-dessus permettent ainsi de planifier la date de réception du résultat d'exécution de la fonction par le système informatique client. Ainsi, lorsqu'un protocole de communication de type clienVserveur est utilisé, par exemple celui connu sous l'acronyme HTTP (HyperText Transfert Protocol), le système informatique client conna^t la date à
laquelle il peut émettre une requête d'obtention du résultat.
Selon un mode préféré de réalisation de l'invention, au cours de l'étape de détermination d'au moins une date de réception, on détermine deux dates de réception du premier résultat, ces deux dates délimitant une plage de réception du premier résultat, la requête d'exécution comportant la plage de réception du premier résultat en vue de recevoir le premier résultat pendant la
plage de réception. -
Cette plage de réception fournit ainsi avantageusement une certaine souplesse au serveur qui peut ainsi choisir une date d'envoi de la réponse en fonction de la bande passante disponible sur le réseau de communication. Selon un autre mode préféré de réalisation de l'invention, au cours de l'étape de détermination de la date de réception, on détermine en outre une période de réception d'au moins un second résultat d'exécution de la fonction, la requête d'exécution comportant la période de réception du second résultat, en vue de recevoir en outre au moins un second résultat d'exécution de la fonction, pendant au moins une seconde plage de réception du second résultat, deux plages de réception successives étant séparées par la période d'obtention
du second résultat.
De cette façon, une seule requête permet d'obtenir plusieurs résultats d'exécution de la fonction, à intervalles réquliers. Par exemple, dans une application de l'invention à un service d'informations boursières, cette caractéristique peut être utilisée pour recevoir périodiquement les cours d'une
valeur boursière donnée.
Selon une caractéristique avantageuse de ce mode préféré de réalisation, au cours de l'étape de détermination d'une date de réception, on détermine un critère d'arrêt d'envoi de résultats par le serveur, la requête
d'exécution comportant ce critère d'arrêt.
Selon un autre mode préféré de réalisation, la requête d'exécution
est définie en langage XML (eXtended Markup Language).
Ce mode de réalisation est particulièrement avantageux, car il peut être mis en _uvre dans des terminaux de types très variés, et profite de
l'infrastructure de communication très répandue du Worid Wide Web.
Selon une autre caractéristique préférée, le résultat reçu par le système informatique client est susceptible d'être un résultat intermédiaire
d'exécution de la fonction.
Cette caractéristique, particulièrement avantageuse lorsque la durée d'exécution de la fonction est longue, permet d'obtenir des informations relatives à l'avancement de l'exécution. Elle peut notamment être utilisée dans
le cas de l'archivage de grandes quantités d'informations.
Selon une autre caractéristique préférée, le résultat reçu par le système informatique client est susceptible de comporter un message d'information. Le serveur peut ainsi notifier au client l'état d'avancement de
l'exécution de la fonction ou des incidents d'exécution.
Selon un deuxième aspect, I'invention vise un procédé d'exécution d'une fonction par un système informatique serveur sur réception d'une requête d'exécution en provenance d'un système informatique client, dans un réseau de communication, caractérisé en ce qu'il comporte les étapes suivantes: extraction de la requête d'exécution d'au moins une date de réception par le client d'un premier résultat d'exécution de la fonction; - prédiction d'un débit de transfert sur le réseau sensiblement à la date de réception; - détermination d'une date d'envoi du premier résultat vers le client, la date d'envoi étant déterminée en fonction de la date de réception et du débit de transfert; - exécution de la fonction et obtention du premier résultat; - envoi du premier résultat au client sensiblement à la date d'envoi. On peut ainsi calculer la date d'envoi du résultat de l'exécution de la fonction de façon à ce que ce résultat soit reçu par le client à la date
spécifiée dans sa requête.
Dans un mode préféré de réalisation, le débit de transfert prédit à la date de réception est obtenu statistiquement à partir de mesures du débit de transfert moyen, ces mesures étant réalisoes à des instants régulièrement
espacés selon un intervalle de temps prédéfini.
Selon un mode préféré de réalisation, I'étape d'exécution de la fonction est précédée par les étapes de: -prédiction d'une durée d'exécution de la fonction applicable avant la date d'envoi; -détermination d'une date d'exécution de la fonction à partir de la durée d'exécution prédite et de la date d'envoi, I'exécution étant déclenchée
sensiblement à la date d'exécution.
Dans un mode préféré de réalisation, la durée d'exécution prédite est calculée en fonction d'une charge de travail du serveur applicable avant la date d'envoi et en fonction d'une durée minimum prédéterminée d'exécution de
la fonction.
Ceci permet avantageusement de déclencher l'exécution de la
fonction à un moment o la charge de travail du serveur est rébuite.
Dans un mode préféré de réalisation, la charge de travail du serveur est calculée statistiquement à partir de mesures de la charge de travail moyenne du serveur, ces mesures étant réalisées à des instants régulièrement
espacés selon un intervalle de temps prédéfini.
Dans un autre mode préféré de réalisation, la requête d'exécution comporte une plage de réception du premier résultat, la plage de réception étant délimitée par deux dates de réception, I'étape d'envoi du premier résultat est alors précédée par: - une étape de détermination d'une plage d'envoi du premier résultat, à partir de la plage de réception du premier résultat, la plage d'envoi étant délimitée par deux dates d'envoi du premier résultat, chacune de ces deux dates d'envoi étant obtenue comme précédemment à partir de l'une des deux dates de réception délimitant la plage de réception; -I'envoi du premier résultat au client ayant lieu pendant la plage
d'envoi du premier résultat.
Le serveur peut ainsi choisir une date d'envoi au sein de la plage d'envoi pour laquelle le débit de transfert prédit sur le réseau de communication
est minimum.
Selon une caractéristique particulière, I'étape d'exécution de la fonction est précédée par une étape de détermination d'une première plage d'exécution de la fonction, la plage d'exécution étant délimitée par deux dates d'exécution, chacune desquelles étant obtenue à partir de la durée minimum d'exécution et de l'une des deux dates d'envoi, I'exécution de la fonction étant
déclenchée pendant la première plage d'exécution.
Le serveur peut ainsi choisir une date d'exécution de la fonction pour laquelle sa charge de travail est minimum, tout en garantissant que le résultat d'exécution de la fonction sera reçu par le client pendant la plage de
réception spécifiée dans sa requête.
Selon un autre mode préféré de réalisation, la requête d'exécution comporte en outre une période de réception d'au moins un second résultat d'exécution de la fonction; le procédé d'exécution étant en outre remarquable en ce que: -on détermine au moins une seconde plage de réception du second résultat à partir des deux dates de réception du premier résultat et de la période de réception du second résultat; -on détermine au moins une seconde plage d'envoi du second résultat à partir de la seconde plage de réception du second résultat, conformément à l'étape de détermination d'une plage d'envoi du premier résultat; - on détermine au moins une seconde plage d'exécution de la fonction à partir des dates délimitant la seconde plage d'envoi, conformément à I'étape de détermination d'une première plage d'exécution; -on exécute la fonction pendant la seconde plage d'exécution et on obtient au moins un second résultat d'exécution; et -on envoie le second résultat d'exécution au client pendant la
seconde plage d'envoi.
De cette façon, et comme précédemment décrit, une seule requête permet au serveur de fournir plusieurs résultats d'exécution de la
fonction au client, à intervalles réguliers.
Selon une caractéristique particulière, la requête d'exécution comporte en outre un critère d'arrêt d'envoi de résultats au système informatique client, et 1'envoi de résultats d'exécution est arrêté dés que le
critère d'arrêt est vérifié.
En pratique le critère d'arrêt est un nombre d'exécutions de la
fonction par le serveur.
Selon une autre caractéristique particulière, le procédé comporte une étape préalable de détermination d'une date de réception au plus tôt du résultat de l'exécution de la fonction par le système informatique client. Dans un mode préféré de réalisation de cette caractéristique particulière, la date de réception au plus tôt est déterminée à partir d'une date de fin d'exécution calculée en fonction de la date courante, de la durée minimum prédétermince d'exécution de la fonction, des mesures de la charge
de travail du serveur, et des mesures du débit de transfert.
Cette caractéristique particulière permet de déterminer si le serveur est capable de fournir le résultat d'exécution de la fonction à la date
escomptée par le client.
Selon une autre caractéristique particulière, si la date de réception au plus tôt est postérieure à la date de réception, on envoie au système
informatique client un résultat comportant un message d'information.
Dans un mode préféré de réalisation, si la date de réception au plus tôt est postérieurç à la date de réception: -on obtient un résultat intermédiaire d'exécution de la fonction; et -on envoie ce résultat intermédiaire au système informatique client
sensiblement à la une date de réception.
En variante, si la date au plus tôt est postérieure à la date de réception, on demande au système informatique client si l'exécution de la fonction par le système informatique serveur doit être annulée ou maintenue, et dans ce deuxième cas: -on exécute la fonction à partir de la date courante; et -on envoie le résultat de cette exécution au système informatique
client dès qu'il est obtenu.
Bien entendu, seule cette variante peut être utilisée si le fonction
ne permet pas d'obtenir de résultat intermédiaire d'exécution.
Corrélativement, I'invention vise un dispositif d'exécution d'une fonction pouvant être intégré dans un système informatique serveur, la fonction étant exécutee sur réception d'une requête d'exécution en provenance d'un système informatique client, dans un réseau de communication, caractérisé en ce qu'il comporte: - des moyens d'extraction, depuis la requête d'exécution, d'au moins une date de réception par le client d'un premier résultat d'exécution de la fonction; - des moyens de prédiction d'un débit de transfert sur le réseau sensiblement à la date de réception; -des moyens de détermination d'une date d'envoi du premier résultat vers le client, la date d'envoi étant déterminée en fonction de la date de réception et du débit de transfert; - des moyens d'exécution de la fonction et d'obtention du premier résultat; - des moyens d'envoi du premier résultat au client sensiblement à
la date d'envoi.
L'invention vise corrélativement une station cliente reliée à un réseau de communication, caractérisoe en ce qu'elle comporte un dispositif de
demande de résultat d'exécution d'une fonction, en conformité avec l'invention.
L'invention vise également une station serveur reliée à un réseau de communication, caractérisée en ce qu'elle comporte un dispositif d'exécution
de fonction, en conformité avec l'invention.
L'invention vise encore un réseau de communication comportant au moins une station cliente en conformité avec l'invention, et au moins une
station serveur en conformité avec l'invention.
L'invention vise également un ordinateur comportant des moyens adaptés à mettre en _uvre le ou les procédés selon l'invention tels qu'exposés supra. L'invention vise aussi un programme d'ordinateur comportant une ou plusieurs séquences d'instructions apte à mettre en _uvre le ou les procèdés selon l'invention tels qu'exposés supra, lorsque ce programme est
executé par un ordinateur.
L'invention vise encore un support d'informations, tel qu'une disquette ou un compact disque (CD), caractérisé en ce qu'il contient un tel
programme d'ordinateur.
Les avantages de ces dispositifs, stations, de cet ordinateur, de ce prog ram me d'ordinateu r, et de ce support d'informations sont identiq ues à ceux
des procédés tels que succinctement exposés ci-dessus.
D'autres aspects et avantages de l'invention apparatront à la
lecture de la description détaillée qui suit d'un mode particulier de réalisation,
donné à titre d'exemple non limitatif. La description se réfère aux dessins qui
1 0I'accompagnent, dans lesquels: -la figure 1 représente sous forme d'organigramme les principales étapes d'un procédé de demande d'exécution par un système informatique client, dans un mode préféré de réalisation de l'invention; -la figure 2 représente sous forme d'organigramme les principales étapes d'une procébure de détermination de paramètres de réception par le système informatique client, dans un mode préféré de réalisation de l'invention; -la figure 3 représente sous forme d'organigramme les principales étapes d'une procédure d'obtention d'un résultat d'execution par le système informatique client, dans un mode préféré de réalisation de l'invention; - la fig ure 4a représente sous forme d'orga nig ram me les principales étapes d'une procédure de mise à jour des statistiques de débit de transfert, par le système informatique serveur, dans un mode préféré de réalisation de l'invention; -la figure 4b représente une table des statistiques de débit de transfert, dans un mode préféré de réalisation de l'invention; - la figure 5a représente sous forme d'organ ig ram me les principales étapes d'une procédure de mise à jour des statistiques de la charge de travail du serveur, par le système informatique serveur, dans un mode préféré de réalisation de l'invention; -la figure 5b représente une table des statistiques de la charge de travail du serveur, dans un mode préféré de réalisation de l'invention; -la figure 6 représente sous forme d'organigramme les principales étapes d'une procédure de réception d'une requête d'exécution par le système informatique serveur, dans un mode préféré de réalisation de l'invention; -la figure 7 représente sous forme d'organigramme les principales étapes d'une procédure de réception d'une requête d'obtention de le système informatique serveur, dans un mode préféré de réalisation de l'invention; -la figure 8 représente de façon schématique un réseau adapté à mettre en _uvre l'invention; -la figure 9 représente de façon schématique un dispositif de demande d'un résultat d'exécution et un dispositif d'exécution selon l'invention, dans un mode préféré de réalisation de l'invention;et - la figure 10 représente de façon schématique un ordinateur adapté à incorporer les composants constituant le dispositif de demande de résultat d'exécution eVou le dispositif d'exécution dans un mode préféré de réalisation de l'invention; La figure 1 représente les étapes E100 à E140 d'un procédé de demande d'exécution par un système informatique client conformément à l'invention. La première étape E100 est une étape d'appel d'une procédure de détermination de paramètres de réception qui va maintenant être décrite en
référence à la figure 2.
La figure 2 représente les principales étapes E200 à E230 d'une procédure de détermination de paramètres de réception par le système
informatique client.
Au cours d'une première étape E200, on détermine une première
date Date1 de réception d'un résultat d'exécution.
Cette date Date1 est affectée à une variable Date1 mémorisée dans un registre du même nom d'une mémoire volatile RAM (102) qui sera
décrite ultérieurement en référence à la figure 10.
Cette date Date1 peut être saisie par un utilisateur du système informatique client, notamment au moyen d'un clavier (104) et d'un écran (103)
décrits en référence à la figure 10.
Dans un autre mode de réalisation de la procédure d'obtention de paramètres de réception, cette date Date1 peut être prédéterminée et lue dans
un registre d'une mémoire morte (101) du système informatique client.
L'étape E200 est suivie par une étape E210 au cours de laquelle on détermine optionnellement une deuxième date Date2 de réception du résultat d'exécution de la fonction. Cette deuxième date de réception est affectée à la variable Date2 et mémorisée dans un registre du méme nom de la
mémoire RAM volatile (102).
Dans un mode préféré de réalisation, on considérera que lorsque la date Date2 n'est pas obtenue à l'étape E210, la variable Date2 est initialisée
avec le contenu de la variable Date1.
Quoi qu'il en soit, on dira par la suite que les deux dates de réception Date1 et Date2 délimitent une plage de réception du résultat
d'exécution de la fonction.
L'étape E210 est suivie par une étape E220 au cours de laquelle on détermine éventuellement une période T de réception d'au moins un second
résultat d'exécution de la fonction.
Cette période T est affectée à une variable T mémorisée dans un
registre du même nom de la mémoire RAM volatile (102).
Lorsqu'au cours de l'étape E220 la période T n'est pas obtenue, la
variable T est initialisée à zéro.
L'étape E220 est suivie par une étape E230 au cours de laquelle on détermine éventuellement un critère d'arrêt d'envoi de résultat par le serveur. Dans le mode préféré de réalisation, ce critère d'arrêt cQrrespond au nombre N d'exécution de la fonction par le système informatique serveur, cette variable N étant mémorisée dans un registre du même nom de la mémoire
RAM volatile (102).
L'étape E230 est la dernière étape de la procédure d'obtention de paramètres de réception selon l'invention. Elle est suivie par l'étape E110 qui va
maintenant être décrite en liaison avec la figure 1.
Au cours de l'étape E110, on prépare une requête d'exécution RE.
Cette requête d'exécution RE est mémorisée dans un registre du
même nom de la mémoire volatile RAM 102.
Un exemple de requête d'exécution RE est également donné à la
figure 1.
Dans le mode préféré de réalisation décrit ici, la requête
d'exécution RE est définie en langage XML.
Cette requête d'exécution RE est délimitée par une balise
ouvrante B1 et une balise fermante B2.
Le nom de ces balises correspond au nom de la fonction
exécutable sur le système informatique serveur.
Dans l'exemple de la figure 1, le nom de cette fonction est "Archive", cette fonction réalisant l'archivage de fichiers lorsqu'elle est exécutée
par le système informatique serveur.
La balise ouvrante B1 comprend des attributs correspondant aux paramètres de réception déterminés précédemment au cours des étapes E210
à E230.
Dans l'exemple de la figure 1, ces paramètres sont: - Date1 = 31/07/010:00; - Date2 = 31/07/01-2:00; - T = 30 jours;
- N =4.
Ces paramètres signifient que le système informatique client demande au système informatique serveur l'exécution de la fonction "Archive", et souhaite obtenir le premier résultat d'exécution de cette fonction pendant la plage de réception délimitée par Date1 et Date2, puis obtenir quatre autres résultats d'exécution de cette fonction dans des plages de réception espacées
les unes des autres de 30 jours.
L'étape E110 est suivie par une étape E120 au cours de laquelle le système informatique client envoie la requête d'exécution RE au système
informatique serveur.
Dans un mode préféré de réalisation, l'envoi de cette requête RE
s'effectue en utilisant le protocole de communication HTTP.
En variante, un autre protocole de communication peut être utilisé, comme par exemple SMTP (Simple Mail Transfer Protocol) ou BEEP (Blocks
Extensible Exchange Protocol).
L'étape E120 est suivie par une étape E130 au cours de laquelle le système informatique client attend un acquittement en provenance du
système informatique serveur.
Cet acquittement comporte, comme décrit ultérieurement en référence à la figure 6, la date de réception du résultat d'exécution de la fonction. Lorsque le système informatique client reçoit cet acquittement, I'étape E130 se termine. Elle est suivie par l'étape E140 au cours de laquelle on mémorise la date de réception du résultat de la fonction reçue dans
l'acquittement à l'étape E130, dans une table Table.
Un exemple de table Table est donné à la figure 1.
11 apparat dans cette table Table que la prochaine date de réception du résultat de la fonction archive est prévue pour le 31/07/01 1:00, cette date de réception étant effectivement contenue dans la plage de réception définie par les paramètres de réception Date1 et Date2, et contenue dans la requête d'exécution RE envoyée au système informatique serveur au cours de
I'étape E 120.
L'étape E140 est la dernière étape du procédé de demande
d'exécution selon l'invention.
Nous allons maintenant décrire en référence à la figure 3, les principales étapes E300 à E320 d'une procébure d'obtention d'un résultat
d'exécution par le système informatique client selon l'invention.
Au cours de la première étape E300, on lit le contenu de la table
Table mise à jour au cours de l'étape E140 précédemment décrite.
Plus précisément, au cours de cette étape E300, on vérifie si les dates mémorisées dans la table Table arrivent à échéance. Ceci peut se faire, par exemple, en comparant la date mémorisée dans la table Table avec la date
courante du systéme informatique client.
Lorsque cette date de réception du résultat d'exécution arrive à échéance, l'étape E300 se termine. Cette étape est alors suivie par une étape E310 au cours de laquelle on envoie au système informatique serveur unerequête d'obtention de résultat.
Cette requête d'obtention de résultat est également, dans le mode préféré de réalisation décrit ici, définie en langage XML et envoyée au système
informatique serveur au moyen du protocole HTTP.
Selon la variante décrite précédemment dans laquelle un autre protocole de communication comme SMTP ou BEEP est utilisé, l'envoi de cette
requête d'obtention n'est pas nécessaire.
L'étape E310 est suivie par une étape E315 au cours de laquelle on reçoit le résultat d'exécution de la fonction, cette fonction ayant été exécutée
par le système informatique serveur.
Le résultat d'exécution de la fonction peut être accompagné d'une date de réception d'un autre résultat d'exécution de la fonction: - soit parce que le système informatique client a demandé au système informatique serveur d'obtenir d'autres résultats d'exécution (N différent de zéro), - soit parce que le résultat reçu est un résultat intermédiaire
d'exécution de la fonction.
L'étape E315 est suivie par une étape E320 au cours de laquelle, on mémorise, le cas échéant et de façon similaire à l'étape E140 déjà décrite, la date de réception d'un autre résultat reçu à l'étape précédente dans la table
Table.
Cette étape E320 est la dernière étape de la procédure
d'obtention de résultat.
Nous allons maintenant décrire en référence à la figure 4a une procébure de mise à jour des statistiques de débit de transfert, cette procédure
étant mise en _uvre par le système informatique serveur.
Dans le mode réalisation décrit ici, le système informatique serveur effectue à des instants régulièrement espacés TR des mesures du débit de transfert moyen sur le réseau de communication, ces mesures statistiques étant mémorisées dans une table de statistiques de débit de
transfert Tb_D.
Au cours de la première étape E400 de cette procédure, on attend
l'intervalle de temps prédéfini TR.
Cette étape E400 est suivie par une étape E410 au cours de laquelle on calcule le débit de transfert qui a été disponible, entre le système informatique client et le système informatique serveur, pendant l'intervalle de
temps TR se terminant à l'instant du calcul.
Ainsi, le débit disponible pendant un intervalle de temps TR donné, est obtenu par le calcul du rapport entre la quantité de données reçues par la station serveur pendant cet intervalle de temps et la valeur de cet intervalle de temps: Données _ reçues Débit(TR)= TR Selon un mode préféré de réalisation de l'invention, le débit disponible à un instant tn est la quantité de données effectivement reçues par la
station cliente entre les instants successifs tn_' et tn.
En pratique, on obtient la quantité de données effectivement reçues par la station serveur entre les instants précités, par le calcul de la différence entre la quantité totale de données reçues par la station serveur à I'instant tn depuis le début du transfert, et ia quantité totale de données reçues par la station cliente à l'instant tn_' depuis le début du transfert: Déhil (l) = Données _ reçues(tn) - Données _ reçues(tn,) Ainsi, à titre d'exemple' supposons d'une part que la station serveur a reçu un paquet de données dont la taille est de 1,8 Mega-octets (millions d'octets, 1 octet = 8 bits), ce paquet de données ayant été transféré le 14 juin 2000 entre 11h35 et 12h20 (durée du transfert: 45 minutes), et que,
d'autre part, l'intervalle de temps de mesure est TR = 15 minutes.
On procèdera alors à la mesure du débit aux instants t, = 11h50, t2 = 12hO5, et t3 = 12h20. D'autre part, on note to = 11h35,1'instant de début du transfert. Si par exemple, à l'instant t, la quantité de données reçues par la station cliente est de 0,45 Méga-octets, à l'instant t2 la quantité de données reçues est 0,75 Méga-octets, et à l'instant t3 le document entier a été reçu (1,8 Méga-octets), alors on aura: D bi () Données_reçues(t)- Donnée_reçues(tO) (0,45-0,0)x lo6 x8 40 0 kb ti- o ISX60 Donnces reçues(t')-Donnée rezes(f) (O. 75-0,45)x106x8 Déhit(t2) = _, = = 26,6 kbps 2-t 15X60 Données_ reçues(t?) - Donnée_ reques(t2) = (1,08 - 0,75) X 10 x 8 = 29,3 k'ps On peut donc dire que le déLit de transfert disponible pour le paquet de donnces considéré a été en moyenne de 40 kbps (kilo-bits par seconde) entre 11h35 et 11h50, de 26,6 kbps en moyenne entre 11h50 et
12hO5, et de 29,3 kbps en moyenne entre 12hO5 et 12h20.
L'étape E410 est suivie par une étape E420 au cours de laquelle on rassemble et organise les donnces de mesure dans la table des statistiques
de débit de transfert Tb_D, telle qu'illustrée à la figure 4b.
L'étape E410 est suivie par l'étape E400 déjà décrite, les étapes
E400 à E420 constituant une boucle.
Nous allons maintenant décrire en référence à la figure 5a, les principales étapes E500 à E520 d'une procédure de mise à jour des statistiques de la charge de travail du serveur, cette procébure étant mise en _uvre par le
système informatique serveur.
Dans le mode réalisation décrit ici, le système informatique serveur effectue à des instants réqulièrement espacés TS des mesures de sa charge de travail moyenne, ces mesures statistiques étant mémorisées dans
une table de statistiques de la charge de travail du serveur Tb_C.
Au cours de la première étape E500 de cette procédure, on attend
l'intervalle de temps prédéfini TS.
Cette étape E500 est suivie par une étape E510 au cours de laquelle on détermine la charge du serveur à partir de la mesure du taux d'utilisation de l'unité centrale (CPU) du serveur, celle-ci pouvant être, à titre
d'exemple, constituée par un ou plusieurs microprocesseurs.
L'étape E510 est suivie par une étape E520 au cours de laquelle on rassemble et organise les données de mesure dans la table des statistiques
de la charge de travail du serveur Tb_C, telle qu'illustrée à ia figure 5b.
A titre d'exemple, on peut lire dans la table Tb_C que la charge de
travail du serveur à la date "MER-14/06/00-12hO5" est 45%.
Nous allons maintenant décrire en référence à la figure 6, les principales étapes E600 à E690 d'une procédure de réception d'une requête
d'exécution RE par le système informatique serveur.
Cette procédure démarre lorsque le système informatique serveur reçoit la requête d'exécution RE envoyée par le système informatique client au
cours de l'étape E120.
Au cours de la première étape E600, on extrait de la requête
d'exécution RE les paramètres de réception du résultat.
Ces paramètres ont été insérés dans la requête d'exécution RE au cours de l'étape E110 par le système informatique client et correspondent aux variables Date1, Date2, T et N. L'étape E600 est suivie par une étape E605 au cours de laquelle on calcule la date de réception au plus tôt DT de réception du résultat
d'exécution par le système informatique client.
Cette date de réception au plus tôt DT est obtenue en considérant que l'on exécute la fonction dès réception de la requête de réception RE, c'est
à-dire à la date courante.
Afin d'obtenir cette date de réception au plus tôt DT, on prédit la durée d'exécution de la fonction en supposant donc que l'on démarre l'exécution de cette fonction à la date courante. Pour prédire cette durée d'exécution, on utilise: - d'une part une durée minimum prédéterminée TE d'exépution de cette fonction, cette durée minimum prédéterminée TE étant la durée effective d'exécution de la fonction par le serveur lorsque toutes les ressources de traitement du serveur sont utilisées pour l'exécution de cette fonction; - et d'autre part la table de statistiques de charge de travail du système informatique serveur Tb_C, cette table Tb_C permettant en particulier de prédire les ressources de traitement du serveur disponible à la date courante. L'estimation de la charge de travail future du serveur selon l'invention, repose sur l'hypothèse selon laquelle l'utilisation du serveur varie très peu d'une semaine à l'autre. Ainsi la charge de travail disponible prévisible d'un jour à venir, à une heure donnée, sera très peu différente (en moyenne) de
celle observée le même jour (et à la même heure) de la semaine précédente.
Ainsi, la valeur prédite de la charge de travail du serveur disponible à une date future est condidérée comme étant égale à la valeur de la charge de travail calculée à une "date équivalente" à l'intérieur de la semaine
qui précède.
En supposant, par exemple, que la durée d'exécution minimum prédéterminée TE de la fonction archivage est 1 heure et que le pourcentage de ressources de traitement du serveur disponible à la date courante est 50%, on prédira que la durée d'exécution de la fonction applicable à la date courante
est deux heures.
Toujours au cours de cette étape E605, après la prédiction de la durée d'exécution de la fonction, on détermine la date de réception au plus tôt DT, en supposant que le résultat de la fonction est envoyé au système
informatique client dès la fin de l'exécution de la fonction.
On évalue à cette effet, une durée présumée de transfert en
utilisant la table de statistiques de débit de transfert Tb_D.
De la même façon, selon l'invention, la valeur prédite du débit de transfert disponible à une date future est condidérée comme étant égale à la valeur du débit de transfert calculee à une "date équivalente" à l'intérieur de la
semaine qui précède.
En supposant que la durée de transfert prévisible du, résultat d'exécution de la fonction entre le système informatique serveur et le système informatique client à la fin de l'exécution est 15 minutes, on prédira que la date au plus tôt DT de réception du résultat d'exécution de la fonction est la date
courante plus 2h15 minutes.
L'étape E605 est suivie par un test E610 au cours duquel on vérifie si la date de réception au plus tôt DT calculée à l'étape E605 est
* supérieure à la date Date2 extraite de la requête d'exécution RE.
Si tel n'est pas le cas, cela signifie que le système informatique serveur est en mesure d'exécuter la fonction et d'envoyer le résultat d'exécution de cette fonction de telle façon que ce résultat soit reçu par le système informatique client avant la fin de la plage de réception délimitée par Date1 et
Date2. Dans ce cas, le résultat du test E610 est négatif.
Ce test est alors suivi par une étape E620 au cours de laquelle on détermine une plage d'envoi du résultat d'exécution de la fonction, cette plage d'envoi étant déterminée à partir de la plage de réception délimitée par Date1 et
Date2 et de la table de statistiques de débit de transfert Tb_D.
Pour cela, on regarde dans la table de statistiques de débit de transfert Tb_D, d'une part les débits de transfert sensiblement applicables à
Date1 à Date2.
A partir de ces débits de transfert, et de la taille du résultat d'exécution de la fonction, on détermine les durées de transfert de ce résultat
sur le réseau de communication applicables sensiblement à Date1 et Date2.
Puis, on détermine les dates d'envoi du résultat d'exécution de la fonction telles que ce résultat soit reçu par le système informatique client aux
dates Date1 et Date2, ces dates d'envoi délimitant la plage d'envoi.
L'étape E620 est suivie par une étape E630 au cours de laquelle on détermine une plage d'exécution, cette plage d'exécution étant déterminée à partir de la plage d'envoi déterminée à l'étape précédente, et de la table de
statistiques de la charge de travail du serveur Tb_C.
Pour cela, on lit dans la table de statistiques de la charge de travail du serveur Tb_C la charge du serveur applicable sensiblement aux dates
délimitant la plage d'envoi.
A partir de ces charges de travail et de la durée minimum prédéterminée TE d'exécution de la fonction, on prédit la durée d'exécution de cette fonction, et on détermine deux dates d'exécution de cette fonction telles que si l'on démarre l'exécution de cette fonction à ces dates, I'exécution sera terminée sensiblement aux dates délimitant la plage d'envoi du résultat. Ces deux dates d'exécution délimitent la plage d'exécution de la fonction. L'étape E630 est suivie par une étape E635 au cours de laqueile
on détermine le début d'exécution de la fonction.
Cette étape E630 consiste plus précisément à déterminer la date d'exécution de la fonction permeffant de réduire le temps d'exécution de la fonction eVou le temps de transfert du résultat d'exécution de la fonction vers le
système informatique client.
Cette date de début d'exécution est bien entendu comprise dans
la plage d'exécution déterminée à l'étape E630.
Da ns une p rem ière va riante, ceffe date de début d 'exécution est détermince afin de répartir au mieux la charge de travail du serveur dans le temps. Dans d'autres variantes, on pourra chercher à minimiser: -la durée de transfert du résultat d'exécution; ou -la durée totale correspondant à la durée d'exécution et au temps
de transfert du résultat.
L'étape E635 est suivie par une étape E640 au cours de laquelle on détermine la date de réception du résultat de la fonction à partir de la date de début d'exécution choisie à l'étape E635. Ceci se fait en déterminant dans un premier temps la date de fin d'exécution de la fonction à partir de la table Tb_C de statistiques de la charge de travail du serveur et de la durce minimum prédéterminée TE d'exécution de la fonction, et en déterminant d'autre part la durce de transfert du résultat de l'exécution de la fonction à partir de la table
Tb_C de statistiques de début de transfert.
L'étape E640 est suivie par une étape E645 au cours de laquelle le système informatique serveur envoie un acquittement au système informatique client. Cet acquittement est attendu par le système informatique
client au cours de l'étape E630 déjà décrite.
Cet acquittement comporte la date de réception du résultat d'exécution de la fonction par le système informatique client, cette date ayant été déterminée au cours de l'étape E640. L'envoi de cet acquittement s'effectue dans le mode préféré de réalisation décrit ici par l'envoi d'un message défini en langage XML, l'envoi de
ce message s'effectuant en utilisant le protocole de communication HTTP.
L'étape E645 est suivie par une étape E650 au cours de laquelle le système informatique serveur attend la date de début d'exécution de la
fonction déterminée au cours de l'étape E635.
Cette étape E650 est ensuite suivie par une étape E655 au cours
de laquelle le système informatique serveur démarre l'exécution de la fonction.
Cette étape E645 est la dernière étape de la procédure de réception d'une requête d'exécution RE par le système informatique serveur De retour au test E610, lorsque la date de réception au plus tôt DT calculée à l'étape E605 est supérieure à la date D2 extraite de la requête
d'exécution RE, le résultat de ce test est positif.
Cela signifie que le système informatique serveur n'est pas en mesure d'exécuter la fonction et d'envoyer le résultat d'exécution de cette fonction de telle façon que ce résultat soit reçu par le système informatique
client pendant la plage de réception délimitée par Date1 et Date2.
Le test E610 est alors suivi par un test E660 au cours duquel on vérifie si dans ce cas particulier, le système informatique serveur doit: envoyer au système informatique client un résultat d'exécution intermédiaire au cours de la plage de réception; -exécuter la fonction et fournir un résultat d'exécution au plus tôt; ou -annuler l'exécution de la fonction. Ce troisième cas ne sera pas
décrit ici.
i Dans un mode préféré de réalisation, chaque fonction exécutée sur le système informatique serveur est associce à un attribut spécifiant si elle
peut fournir un résultat intermédiaire d'exécution ou non.
Si tel est le cas, le résultat du test E660 est positif. Ce test alors suivi par une étape E665 au cours de laquelle on affecte la date courante à la
date de début d'exécution de la fonction.
L'étape E665 est suivie par une étape E670 au cours de laquelle on détermine, à partir de cette date de début d'exécution, la date de réception
du résultat intermédiaire par le système informatique client.
Cela se fait en sélectionnant dans la table de statistiques de début de transfert Tb_D une date de réception du résultat intermédiaire d'exécution de la fonction tel que le débit de transfert sur le réseau de communication à
cette date est faible.
L'étape E670 est suivie par l'étape E675 similaire à l'étape E645
déjà décrite.
Au cours de cette étape E675, le système informatique serveur envoie un message d'acquittement au système informatique client contenant d'une part la date de réception déterminée à l'étape E670, et d'autre part, un message indiquant au système informatique client que le résultat d'exécution reçu à cette date de réception sera un résultat intermédiaire d'exécution de la fonction. L'étape E675 est suivie par l'étape E650 d'attente de début d'exécution de la fonction. Dans ce cas, la durée de cette étape est nulle puisqu'il a été prévu à l'étape E665 de démarrer l'exécution de la fonction à ia
date courante.
De retour au test E660, lorsqu'il est prévu que le système informatique serveur envoie le résultat final de l'exécution de la fonction au système informatique client dès que le résultat est obtenu, (en dehors de la plage de réception délimitée par Date1 et Date2), le résultat du test E660 est
négatif.
24 2829330
Ce test E660 est alors suivi par une étape E680 au cours de laquelle on affecte la date courante à la date de début d'exécution de la
fonction. Cette étape E680 est similaire à l'étape E665 déjà décrite.
Cette étape E680 est suivie par une étape E685 au cours de laquelle on détermine la date de fin d'exécution de la fonction en supposant que le début de l'exécution de la fonction démarre à la date courante. Cette date de fin d'exécution est déterminée à partir de la table de statistiques de la charge de
travail du serveur Tb_C.
L'étape E685 est suivie par une étape E690 au cours de laquelle on détermine la date de réception du résultat final d'exécution de la fonction en supposant que l'envoi de ce résultat vers le système informatique client a lieu
dès la fin de l'exécution de la fonction.
Cette date de réception est déterminée à partir de la table de
statistiques de débit de transfert Tb_D.
L'étape E690 est alors suivie par l'étape E675 déjà décrite, dans laquelle le message d'acquittement au système informatique client contient d'une part la date de réception déterminée à l'étape E690, et d'autre part, un message indiquant au système informatique client que l'exécution de la fonction
est en cours.
Nous allons maintenant décrire en référence à figure 7 les principales étapes E700 à E745 d'une procédure de réception d'une requête d'obtention de résultat, ces étapes étant mises en _uvre par le système
informatique serveur.
Cette procédure démarre lorsque le système informatique serveur reçoit la requête d'obtention de résultat envoyée par le système informatique
client au cours de l'étape E310.
Au cours d'une première étape E700, on vérifie si l'exécution de la
fonction est termince.
Si tel est le cas, on affecte le résultat d'exécution de cette fonction à une variable Res, cette variable étant mémorisée dans un registre du même
nom de la mémoire RAM volatile (102).
2829330
L'étape E705 est suivie par un test E710 au cours duquel on vérifie si l'une au moins des variables T et N extraites de la requête d'exécution au cours de l'étape E600 est nulle Si tel est le cas, cela signifie que l'exécution de la fonction qui vient de se terminer était la dernière exécution associée à la requête en cours
de traitement.
Le résultat du test E710 est alors positif. Ce test est suivi par une étape E715 au cours de laquelle on envoie au client le résultat d'exécution de la fonction. En revanche, si les variables T et N ne sont pas nulles, cela signifie qu'au moins un résultat d'une autre exécution de la fonction doit être
envoyé au système informatique client.
Le résultat du test E710 est alors négatif. Ce test est suivi par une étape E720 au cours de laquelle on détermine la date de réception du résultat
d'exécution suivant.
Cette détermination s'effectue de façon similaire à la détermination de la date de réception précédemment décrite, en remplaçont la plage de réception délimitée par Date1 et Date2 par une plage de réception délimitée par des dates Date1' et Date2' telles que: - Date1'=Date1 +T et
- Date2'=Date2+T.
L'étape E720 est suivie par une étape E725 au cours de laquelle
la variable N est décrémentée d'une unité.
L'étape E725 est suivie par une étape E730 au cours de laquelle on envoie au client, d'une part le résultat d'exécution de la fonction Res, et
d'autre part, la date de réception du résultat d'exécution suivant de la fonction.
Lorsqu'au cours du test E700,1'exécution de la fonction n'est pas
terminée, le résultat de ce test est négatif.
Ce test est alors suivi par une étape E735 au cours de laquelle on obtient un résultat intermédiaire d'exécution de la fonction, ce résultat intermédiaire étant affecté à une variable Resint, cette variable étant
mémorisée dans la mémoire RAM volatile (102).
L'étape E735 est suivie par une étape E740 au cours de laquelle on détermine la date de réception du résultat suivant d'exécution de la fonction par le système informatique client, cette date de réception pouvant soit être un autre résultat intermédiaire d'exécution de la fonction, soit être le résultat final d'exécution de la fonction. Cette détermination s'effectue de façon similaire à la
détermination de la première date de réception telle que précédemment décrite.
L'étape E740 est suivie par une étape E745 au cours de laquelle on envoie au système informatique client, d'une part le résultat intermédiaire, et
d'autre part, la date suivante de réception du résultat d'exécution de la fonction.
Les étapes E715, E730 et E745 terminent la procébure de
réception d'une requête d'obtention du résultat.
En référence à la figure 8 on va décrire un exemple de réseau
adapté à mettre en _uvre l'invention.
Le réseau 80 comporte en réalité deux sous-réseaux 81, 82.
Chacun des sous-réseaux comporte une pluralité d'ordinateurs et de périphériques reliés entre eux au travers du réseau. A titre d'exemple, les sous réseaux 81 et 82 peuvent être des réseaux locaux (LAN) basés sur des architectures connues telles que Ethernet ou Token Ring, ou bien des réseaux
d'entreprise connoctés entre eux via un réseau téléphonique.
Le sous-réscau 81 comporte ainsi dans cet exemple trois ordinateurs 83a, 83b et 83c et une imprimante 84 connectée au sous-réseau 81
via l'ordinateur 83c.
Le second sous-réseau 82 comporte trois ordinateurs 84a, 84b et
84c et une imprimante 85 reliée au sous-réseau 82 par l'ordinateur 84c.
Ces deux sous-réseaux 81 et 82 sont reliés par l'intermédiaire des ordinateurs 83a et 84a, appartenant respectivement au premier sous-réseau 81 et au second sous-réseau 82, chacun de ces ordinateurs 83a, 84a incorporant un modem, ces modem étant reliés par l'intermédiaire d'un réseau de communication téléphonique 86, et à titre d'exemple via un commutateur 87 qui se trouve chez un même fournisseur d'accès (en anglais service provider),
commun aux deux réseaux 81, 82.
27 2829330
Cette structure permet aux deux sous-réseaux 81, 82 de communiquer, de telle sorte qu'un utilisateur du premier sous-réseau 81 peut utiliser les éléments du second sous-réseau 82 comme s'ils appartenaient
physiquement au premier sous-réseau 81, et réciproquement.
Les sous-réseaux 81 et 82 peuvent être également intégrés dans un réseau de communication planétaire, tel que le réseau Internet, bâti au dessus d'un protocole de communication permettant aux ordinateurs connoctés
au réseau de communiquer (par exemple HTTP).
Pour chacun des sous-réseaux l'accès à Internet est réalisé par
exemple par l'intermédiaire du réseau de communication téléphonique 86.
A titre d'exemple, les systèmes informatiques client et serveur cités précédemment sont respectivement les ordinateurs 83b, et 84b. Ils seront
décrits ultérieurement en référence à la figure 10.
En référence à la fiigure 9, on va maintenant décrire un dispositif CL de demande d'un résultat d'exécution d'une fonction et un dispositif SE
d'exécution de cette fonction conformément à la présente invention.
Le dispositif CL de demande d'un résultat d'exécution d'une
fonction comporte une unité 90 de détermination de paramètres de réception.
Cette unité 90 de détermination de paramètres de réception permet de déterminer au moins une date Date1 de réception d'un résultat d'exécution et éventuellement: - une deuxième date Date2 de réception du résultat d'exécution de la fonction; -une période T de réception d'au moins un deuxième résultat d'exécution de la fonction; et -un critère d'arrêt N d'envoi de résultats par le - système
informatique serveur.
Le dispositif CL de demande d'un résultat d'exécution d'une fonction comporte également une unité 91 d'envoi d'une requête RE d'exécution. Cette unité 91 d'envoi d'une requête d'exécution RE est apte à créer, en langage XML, une requête d'exécution RE à partir des paramètres de
28 2829330
réception déterminés par l'unité 90 de détermination de paramètres de réception. Cette unité 91 d'envoi d'une requête est également adaptée à envoyer la requête d'exécution RE au système informatique serveur selon un protocole de communication, par exemple HTTP. Le dispositif CL de demande d'un résultat d'exécution d'une fonction comporte également une unité 92 de réception d'un résultat
d'exécution de la fonction en provenance du système informatique serveur.
Cette unité 92 de réception d'un résultat est également apte à vérifier si les dates mémorisées dans la table Table arrivent à échéance et à envoyer une requête d'obtention de résultat au système informatique serveur
lorsque c'est la cas.
D'une façon générale, le dispositif CL de demande d'un résultat d'exécution d'une fonction comporte des moyens adaptés à mettre en _uvre le procédé de demande de résultat d'exécution d'une fonction décrit
précédemment en référence aux figures 1 à 3.
Le dispositif SE d'exécution d'une fonction comporte une unité 93
de réception d'une requête RE d'exécution.
Cette unité 93 de réception d'une requête d'exécution est en particulier apte à communiquer avec l'unité 91 d'envoi d'une requête du
dispositif CL, par exemple au moyen du protocole de communication HTTP. Le dispositif SE d'exécution d'une fonction comporte également une unité
94 d'extraction des paramètres de réception à partir de la requête RE d'exécution reçue par l'unité 93 de réception, ces paramètres ayant été
déterminés dans le dispositif CL par l'unité 90 de détermination de paramètres.
Le dispositif SE d'exécution d'une fonction comporte aussi une unité 95 de détermination d'une date au plus tôt DT de réception du résultat
d'exécution par le système informatique client.
Cette unité 95 de détermination est en particulier apte à mettre en
_uvre l'étape E605 décrite précédemment en référence à la figure 6.
Le dispositif SE d'exécution d'une fonction comporte aussi une
unité 96 de prédiction.
Cette unité 96 de prédiction est en particulier apte à prédire un débit de transfert sur le réseau de communication et une durée d'exécution de
la fonction sensiblement à une date donnée.
Dans un mode préféré de réalisation ces prédictions sont effectuées statistiquement par des mesures périodiques respectivement du
débit de transfert moyen sur le réseau et de la charge moyenne du serveur.
L'unité 96 de prédiction est également apte à déterminer une date d'envoi d'un résultat vers le système informatique client en fonction d'une date souhaitée de réception et d'un débit de transfert prédit, ainsi qu'une date d'exécution de la fonction à partir d'une durée d'exécution prédite et d'une date d'envoi. Le dispositif SE d'exécution d'une fonction comporte également une unité 97 d'exécution apte a démarrer 1'exécution d'une fonction à une date d'exécution donnée, et à obtenir des résultats intermédiaires ou définitifs
d'exécution de cette fonction à des dates déterminées.
Le dispositif SE d'exécution d'une fonction comporte également une unité 98 d'envoi du résultat d'exécution d'une fonction à destination de
l'unité 92 de réception d'un résultat d'exécution du système informatique client.
D'une façon générale, le dispositif SE d'exécution d'une fonction comporte des moyens adaptés à mettre en _uvre le procédé d'exécution d'une
fonction décrit précédemment en référence aux figures 4a à 7.
En référence maintenant à la figure 10, on va décrire un ordinateur adapté à incorporer les composants constituant le dispositif de demande de résultat d'exécution eVou le dispositif d'exécution conformément à
la présente invention.
Dans ce mode de réalisation, les moyens constituant le-dispositif de demande d'au moins un résultat d'exécution d'une fonction et le dispositif d'exécution d'une fonction selon l'invention sont essentiellement des
composants logiciels ou programmes.
Par conséquent, ces composants logiciels comportent une ou plusieurs séquences d'instructions dont l'exécution par ledit ordinateur permet
la mise en _uvre des procédés selon l'invention.
2829330
Dans la figure 10, I'ordinateur 10 qui peut être typiquement un microordinateur ou une station de travail, comporte de façon classique une unité centrale (CPU) 100, reliée à une mémoire morte (ROM) 101 et à une
mémoire vive RAM (102), ainsi qu'à un bus de données 112.
Le bus de données 112 permet la communication entre ies
différents sous-éléments de l'ordinateur 10, ou les éléments qui lui sont liés.
Cependant, la communication entre les différents sous-éléments de l'ordinateur n'est pas limitée au bus 112. En particulier, I'unité centrale 100 est susceptible de communiquer des instructions à tout sousélément de l'ordinateur 10
directement ou par l'intermédiaire d'un autre sous-élément de l'ordinateur 10.
L'ordinateur 10 comporte une interface de communication 110 relié à un réseau de communication tel que le réscau 80 (représenté à la figure 8) tel que le réseau Internet et apte à recevoir et transmettre des données par exemple en utilisant le protocole HTTP. Cet interface de communication 110
comprend par exemple un modem de type connu de l'homme de l'art.
L'ordinateur 10 comporte également de façon classique un moyen de stockage 106 tel que par exemple un disque dur. Il peut également comporter un lecteur de disquettes 107, un lecteur de CD-ROM 108 et un
lecteur de cartes de format dit PC-CARD 109.
Une disquette 7, un disque compact (CD) 8, une carte 9 de type PC-CARD, destinées à être lues respectivement par le lecteur de disquettes 107, le lecteur de CD-ROM 108 et le lecteur de cartes 109; ainsi que le disque dur 106, peuvent être utilisés pour le stockage de documents transférés selon l'invention, ainsi que pour le stockage du code logiciel permettant la mise en
_uvre du procèdé de transfert selon l'invention.
Selon un mode préféré de réalisation, le code exécutable du programme permettant de mettre en _uvre le procédé de transfert, est
mémorisé dans le disque dur 106.
Selon une variante de réalisation, le code exécutable de ce
programme est stocké dans la ROM 101.
31 2829330
Selon une autre variante de réalisation, le code exécutable du programme peut être téléchargé à partir du réseau de communication 1 via
l'interface de communication 110 pour être mémorisé sur le disque dur 106.
L'interface de communication 110 est par exemple un navigateur Internet (en anglais web browser). Lors.de l'exécution du programme, les variables créées et
modifiées sont mémorisées dans des registres de la RAM (102).
L'ordinateur 3 comporte en outre un écran 103 permettant de servir d'interface graphique entre le programme selon l'invention et l'utilisateur, celui-ci pouvant formuler des requêtes à l'aide par exemple d'un dispositif de
pointage tel qu'une souris 105, ou bien à l'aide d'un clavier 104.
L'ordinateur 10 comporte en outre divers périphériques, tels qu'une imprimante 14 permettant par exemple d'imprimer des documents téléchargés, ou un télécopieur 17. Ces périphériques sont reliés à l'ordinateur
via une carte d'entrée/sortie 111.
Bien entendu, de nombreuses modifications peuvent être apportées au modes de réalisation de l'invention décrits ci-dessus sans sortir
du cadre de l'invention.
Claims (30)
1. Procédé de demande, par un système informatique client (83b), d'au moins un résultat (Res) d'exécution d'une fonction (Archive) exécutable sur un système informatique serveur (84b), dans un réseau (80) de communication, caractérisé en ce qu'il comporte les étapes suivantes: détermination (E200) d'au moins une date (Date1) de réception d'un premier résultat (Res) d'exécution; - envoi (E120) d'une requête (RE) d'exécution à destination du serveur (84b), la requête (RE) d'exécution comportant ladite au moins une date (Date1) de réception, en vue de recevoir ledit premier résultat (Res)
sensiblement à ladite date (Date1) de réception.
2. Procédé selon la revendication 1, caractérisé en ce que, au cours de ladite étape de détermination (E200) d'au moins une date (Date1) de réception, on détermine (E200, E210) deux dates (Date1, Date2) de réception dudit premier résultat (Res), ces deux dates (Date1, Date2) délimitant une plage de réception dudit premier résultat (Res), ladite requête (RE) d'exécution comportant ladite plage (Date1, Date2) de réception dudit premier résultat (Res) en vue de recevoir ledit premier résultat (Res) pendant ladite plage de réception
(Date1, Date2).
3. Procédé selon la revendication 2, caractérisse en ce que, au cours de ladite étape de détermination (E200) d'au moins une date (Date1) de réception, on détermine en outre (E220) une période (T) de réception d'au moins un second résultat (Res) d'exécution de ladite fonction (Archive), ladite requête (R E) d'exécution comportant ladite période (T) de réception d ud it a u moins un second résultat (Res), en vue de recevoir en outre au moins un second résultat (Res) d'exécution de ladite fonction (Archive), pendant au moins une seconde plage de réception dudit au moins un second résultat, deux plages
33 2829330
de réception successives étant séparées par lad ite période (T) d'obtention dud it
au moins un second résultat (Res).
4. Procédé selon la revendication 3 caractérisé en ce que, au cours de ladite étape de détermination (E200) d'au moins une date (Date1) de réception, on détermine un critère d'arrêt (N) d'envoi de résultats (Res) par ledit serveur (84b), ladite requête (RE) d'exécution comportant ledit critère
d'arrêt (N).
5. Procédé selon l'une quelconque des revendications 1 à 4
caractérisé en ce que ladite requête (RE) d'exécution est définie en langage XML.
6. Procédé selon l'une queiconque des revendications 1 à 5
caractérisé en ce qu'un résultat (Res) reçu par le système informatique client (83b) est susceptible d'être un résultat intermédiaire (Resint) d'exécution de
ladite fonction (Archive).
7. Procédé selon l'une quelconque des revendications 1 à 6
caractérisé en ce qu'un résultat (Res) reçu par le système informatique client
(83b) est susceptible de comporter un message d'information (Message).
8. Procédé d'exécution d'une fonction (Archive) par un système informatique serveur (84b) sur réception d'une requête (RE) d'exécution en provenance d'un système informatique client (83b), dans un réseau (80) de communication, caractérisé en ce qu'il comporte les étapes suivantes: extraction (E600) de ladite requête (RE) d'exécution d'au moins une date (Date1) de réception par ledit client (83b) d'un premier résultat (Res) d'exécution de ladite fonction (Archive); - prédiction (E620) d'un débit de transfert sur ledit réseau (80) sensiblement à iadite date (Date1) de réception; -détermination (E620) d'une date d'envoi dudit premier résultat (Res) vers ledit client (83b), ladite date d'envoi étant déterminée en fonction de ladite au moins une date (Date1) de réception et dudit débit de transfert; -exécution (E655) de ladite fonction (Archive) et obtention (E705) dudit premier résultat (Res); -envoi (E715) dudit premier résultat (Res) audit client (83b)
sensiblement à ladite date (Date1) d'envoi.
9. Procédé selon la revendication 8, caractérisé en ce que ledit débit de transfert prédit à ladite date de réception est obtenu statistiquement à partir de mesures (Tb_D) du débit de transfert moyen, lesdites mesures (Tb_D) étant réalisées à des instants (t) réqulièrement espacés selon un intervalle de
temps (TR) prédéfini.
10. Procédé selon la revendication 8 ou 9, caractérisé en ce que ladite étape d'exécution (E655) de ladite fonction (Archive) est précédée par les étapes de: - prédiction (E630) d'une durée d'exécution de la fonction (Archive) applicable avant ladite date d'envoi; -détermination (E630) d'une date d'exécution de ladite fonction (Archive) à partir de la d urce d 'exécution prédite et de lad ite date d'envoi, lad ite
exécution étant déclenchée sensiblement à ladite date d'exécution.
11. Procédé selon la revendication 10, caractérisé en ce que la durée d'exécution préd ite est calculée en fonction d'une charge de travail dud it serveur (84b) applicable avant ladite date d'envoi et en fonction d'une durée
(TE) minimum prédétermince d'exécution de ladite fonction (Archive).
12. Procédé selon la revendication 11, caractérisé en ce que la charge de travail du serveur (84b) applicable avant ladite date est calculée statistiquement à partir de mesures (Tb_C) de la charge de travail moyenne du
2829330
serveur (84b), lesdites mesures étant réalisées à des instants réqulièrement
espacés selon un intervalle de temps (TS) prédéfini.
13. Procédé selon l'une quelconque des revendications 8 à 12,
caractérisé en ce que: -ladite requête (RE) d'exécution comporte une plage de réception (Date1, Date2) dudit premier résultat (Res), ladite plage de réception étant délimitée par deux dates de réception, ladite étape d'envoi (E715) dudit premier résultat (Res) est précédée par: -une étape de détermination d'une plage d'envoi dudit premier résultat (Res), à partir de ladite plage de réception (Date1, Date2) dudit premier résultat (Res), ladite plage d'envoi étant délimitée par deux dates d'envoi du premier résultat, chacune de ces deux dates d'envoi étant obtenue à partir de l'une des deux dates de réception (Date1, Date2) délimitant ladite plage de réception, selon les étapes d'extraction (E600) , de prédiction (E620), et de détermination d'une plage d'envoi (E620); et en ce que -on envoie (E715) ledit premier résultat (Res) audit client (83b)
pendant ladite plage d'envoi du premier résultat.
14. Procédé selon la revendication 13, caractérisé en ce que iadite étape d'exécution (E655) de ladite fonction (Archive) est précédée par une étape de: - détermination d'une première plage d'exécution de ladite fonction (Archive), ladite plage d'exécution étant délimitée par deux dates d'exécution, chacune desquelles étant obtenue à partir de ladite durce (TE) minimum d'exécution et de l'une desdites deux dates d'envoi, ladite exécution de la fonction (Archive) étant déclenchée (E655) pendant ladite première plage d'exécution.
15. Procédé selon la revendication 14, caractérisé en ce que lad ite req uête (RE) d'exécution comporte en outre une période (T) de réception d'au moins un second résultat (Res) d'exécution de ladite fonction (Archive); et en ce que: -on détermine au moins une seconde plage (Date1', Date2') de réception dudit au moins un second résultat (Res) à partir desUites deux dates (Date1, Date2) de réception du premier résultat (Res) et de ladite période (T) de réception dudit au moins un second résultat (Res); -on détermine au moins une seconde plage d'envoi dudit au moins un second résultat (Res) à partir de ladite seconde plage de réception (Date1', Date2') dudit au moins un second résultat (Res), conformément à ladite étape (E620) de détermination d'une plage d'envoi dudit premier résultat; -on détermine au moins une seconde plage d'exécution de ladite fonction (Archive) à partir des dates délimitant ladite seconde plage d'envoi, conformément à ladite étape (E630) de détermination d'une première plage d'exécution; - on exécute (E655) la fonction (Archive) pendant ladite au moins une seconde plage d'exécution et on obtient au moins un second résultat (Res) d'exécution; et - on envoie (E715) ledit au moins un second résultat (Res)
d'exécution au client (83b) pendant ladite au moins une seconde plage d'envoi.
16. Procédé selon la revendication 15, caractérisé en ce que ladite requête (RE) d'exécution comporte en outre un critère d'arrêt (N) d'envoi de résultats (Res) audit système informatique client (83b), I'envoi de résultats
d'exécutions étant arrêté dés que ledit critère d'arrêt (N) est vérifié.
17. Procédé selon l'une quelconque des revendications 12 à 16,
caractérisé en ce qu'il comporte une étape préalable de détermination (E605) d'une date de réception au plus tôt (DT) du résultat (Res) de l'exécution de la
fonction (Archive) par le système informatique client (83b).
18. Procédé selon la revendication 17, caractérisé en ce que ladite date de réception au plus tôt (DT) est déterminée à partir d'une date de fin d'exécution calculée en fonction de la date courante, de la durée (TE) minimum prédéterminée d'exécution de la fonction (Archive), desUites mesures (Tb_C) de la charge de travail du serveur (84b), et desdites mesures (Tb_D) du
débit de transfert.
19. Procédé selon la revendication 17 ou 18, caractérisé en ce que si ladite date de réception au plus tôt (DT) est postérieure à ladite au moins une date (Date1) de réception, on envoie au système informatique client (83b)
un résultat comportant un message d'information (Message).
20. Procédé selon l'une quelconque des revendications 17 à 19,
caractérisé en ce que si la date de réception au plus tôt (DT) est postérieure à ladite au moins une date (Date1) de réception: -on obtient un résultat intermédiaire (Resint) d'exécution de la fonction (Archive); et -on envoie (E745) ledit résultat intermédiaire (Resint) audit système informatique client (83b) sensiblement à ladite au moins une date
(Date1) de réception.
21. Procédé selon l'une quelconque des revendications 8 à 20
caractérisé en ce q ue la req uête (RE) est défin ie en langage XM L.
22. Dispositif de demande d'au moins un résultat (Res) d'exécution d'une fonction (Archive) exécutable sur un système informatique serveur (84b), ledit dispositif (CL) pouvant être intégré dans un système informatique client (83b), dans un réseau (80) de communication, caractérisé en ce qu'il comporte: - des moyens (90) de détermination d'au moins une date (Date1) de réception d'un premier résultat (Res) d'exécution; - des moyens (91) d'envoi d'une requête (RE) d'exécution à destination du serveur (84b), la requête (RE) d'exécution comportant ladite au moins une date (Date1) de réception, en vue de recevoir ledit premier résultat (Res) sensiblement à ladite date (Date1) de réception; et
- des moyens (92) de réception dudit premier résultat.
23. Dispositif d'execution d'une fonction (Archive) pouvant être intégré dans un système informatique serveur (84b), ladite fonction (Archive) étant exécutée sur réception d'une requête (RE) d'exécution en provenance d'un système informatique client (83b), dans un réseau (80) de communication, caractérisé en ce qu'il comporte: - des moyens (94) d'extraction, depuis ladite requête (RE) d'exécution, d'au moins une date (Date1) de réception par ledit client (83b) d'un premier résultat (Res) d'exécution de ladite fonction (Archive); - des moyens (96) de prédiction d'un débit de transfert sur ladit réseau (80) sensiblement à ladite date (Date1) de réception; - des moyens (96) de détermination d'une date d'envoi dudit premier résultat vers ledit client (83b), ladite date d'envoi étant déterminée en fonction de ladite au moins une date (Date1) de réception et dudit débit de transfert; -des moyens (97) d'exécution de ladite fonction (Archive) et d'obtention dudit premier résultat (Res); des moyens (98) d'envoi dudit premier résultat (Res) audit client
(83b) sensiblement à ladite date (Date1) d'envoi.
24. Dispositif selon la revendication 23, caractérisé en ce qu'il comporte: -des moyens (96) de prédiction d'une durée d'exécuti-on de la fonction (Archive) applicable avant ladite date d'envoi; et -des moyens (96) de détermination d'une date d'exécution de ladite fonction (Archive) à partir de la durée d'exécution prédite et de ladite date (Date1) d'envoi, ladite exécution étant déclenchée sensiblement à ladite date d'exécution.
25. Dispositif selon l'une quelconque des revendications 23 ou 24,
caractérisé en ce qu'il comporte des moyens (95) de détermination d'une date de réception au plus tôt (DT) du résultat de l'exécution de la fonction (Archive)
par le système informatique client (83b).
26. Dispositif selon la revendication 25, caractérisé en ce que lesdits moyens (98) d'envoi du premier résultat (Res) sont adaptés à envoyer un résultat comportant un message d'information (Message) au système informatique client (83b), si ladite date de réception au plus tôt (DT) est
postérieure à ladite au moins une date (Date1) de réception.
27. Dispositif selon l'une quelconque des revendications 25 ou 26,
caractérisé en ce qu'il comporte des moyens (97) d'obtention d'un résultat
intermédiaire d'exécution de la fonction (Archive).
28. Station cliente reliée à un réseau (80) de communication, caractérisée en ce qu'elle comporte un dispositif (CL) de demande d'au moins
un résultat (Res) d'exécution d'une fonction (Archive), selon la revendication 22.
29. Station serveur reliée à un réseau (80) de communication, caractérisée en ce qu'elle comporte un dispositif (SE) d'exécution d'une fonction
(Archive), selon l'une quelconque des revendications 23 à 27.
30. Réseau de communication comportant au moins une station cliente selon la revendication 28, et au moins une station serveur selon la
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0111330A FR2829330B1 (fr) | 2001-08-31 | 2001-08-31 | Procede de demande de reception du resultat d'execution d'une fonction a distance a une date predeterminee |
| JP2002257059A JP2003196234A (ja) | 2001-08-31 | 2002-09-02 | 所定時間に機能の遠隔実行結果を受信すべく要求する方法 |
| US10/232,405 US20030055916A1 (en) | 2001-08-31 | 2002-09-03 | Method for requesting to receive the result of the remote execution of a function at a predetermined time |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0111330A FR2829330B1 (fr) | 2001-08-31 | 2001-08-31 | Procede de demande de reception du resultat d'execution d'une fonction a distance a une date predeterminee |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2829330A1 true FR2829330A1 (fr) | 2003-03-07 |
| FR2829330B1 FR2829330B1 (fr) | 2003-11-28 |
Family
ID=8866875
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0111330A Expired - Fee Related FR2829330B1 (fr) | 2001-08-31 | 2001-08-31 | Procede de demande de reception du resultat d'execution d'une fonction a distance a une date predeterminee |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20030055916A1 (fr) |
| JP (1) | JP2003196234A (fr) |
| FR (1) | FR2829330B1 (fr) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2841998B1 (fr) * | 2002-07-04 | 2004-10-22 | Canon Kk | Procede d'execution sur une station d'un reseau de communication d'un programme informatique represente dans un langage de balisage |
| US8051188B2 (en) | 2002-09-05 | 2011-11-01 | Canon Kabushiki Kaisha | Method of proposing a service via a description document of such a service |
| FR2852177B1 (fr) * | 2003-03-03 | 2005-06-24 | Canon Kk | Procede de proposition d'un service fourni par un ordinateur serveur dans un reseau de communication |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5774479A (en) * | 1995-03-30 | 1998-06-30 | Motorola, Inc. | Method and system for remote procedure call via an unreliable communication channel using multiple retransmission timers |
| WO2000058900A1 (fr) * | 1999-03-31 | 2000-10-05 | The Chase Manhattan Bank | Systeme de gestion de fonds financiers et de conformite aux directives en matiere d'investissement de portefeuille |
Family Cites Families (39)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0628322A (ja) * | 1992-07-10 | 1994-02-04 | Canon Inc | 情報処理装置 |
| JPH06187226A (ja) * | 1992-12-18 | 1994-07-08 | Fuji Xerox Co Ltd | ファイル管理システム |
| JPH07129510A (ja) * | 1993-11-01 | 1995-05-19 | Toshiba Corp | コンピュータシステム |
| US5758155A (en) * | 1994-10-18 | 1998-05-26 | Hewlett-Packard Company | Method for displaying progress during operating system startup and shutdown |
| US5920701A (en) * | 1995-01-19 | 1999-07-06 | Starburst Communications Corporation | Scheduling data transmission |
| JP4309480B2 (ja) * | 1995-03-07 | 2009-08-05 | 株式会社東芝 | 情報処理装置 |
| JPH0950412A (ja) * | 1995-08-10 | 1997-02-18 | Hitachi Ltd | 遠隔手続き呼び出し方法およびシステム |
| JPH1091685A (ja) * | 1996-09-17 | 1998-04-10 | Hitachi Ltd | 多段階空き時間検索システム |
| US6745224B1 (en) * | 1996-12-06 | 2004-06-01 | Microsoft Corporation | Object framework and services for periodically recurring operations |
| JPH1153326A (ja) * | 1997-07-30 | 1999-02-26 | Internatl Business Mach Corp <Ibm> | 分散処理システム、クライアントノード、サーバノードおよび分散処理方法 |
| US6134596A (en) * | 1997-09-18 | 2000-10-17 | Microsoft Corporation | Continuous media file server system and method for scheduling network resources to play multiple files having different data transmission rates |
| JP3228708B2 (ja) * | 1998-04-03 | 2001-11-12 | パイオニア株式会社 | 伝送システムにおける受信インターフェース装置 |
| US6766315B1 (en) * | 1998-05-01 | 2004-07-20 | Bratsos Timothy G | Method and apparatus for simultaneously accessing a plurality of dispersed databases |
| JP2000123023A (ja) * | 1998-10-13 | 2000-04-28 | Hitachi Ltd | 個人別ページ生成方法及びその実施装置並びにその処理プログラムを記録した媒体 |
| US6742141B1 (en) * | 1999-05-10 | 2004-05-25 | Handsfree Networks, Inc. | System for automated problem detection, diagnosis, and resolution in a software driven system |
| JP3733784B2 (ja) * | 1999-05-21 | 2006-01-11 | 株式会社日立製作所 | パケット中継装置 |
| US6937609B1 (en) * | 1999-05-25 | 2005-08-30 | Cingular Wireless Ii, Inc. | Method for improving efficiency in a time sharing network |
| US6330719B1 (en) * | 1999-06-30 | 2001-12-11 | Webtv Networks, Inc. | Interactive television receiver unit browser that waits to send requests |
| US6526434B1 (en) * | 1999-08-24 | 2003-02-25 | International Business Machines Corporation | System and method for efficient transfer of data blocks from client to server |
| JP3471694B2 (ja) * | 2000-01-31 | 2003-12-02 | 日本電気株式会社 | 網管理システムにおけるトラヒック収集方式 |
| JP2001338233A (ja) * | 2000-03-24 | 2001-12-07 | Sony Corp | 電子機器、使用時間による課金システムおよび方法、課金処理装置、記録媒体、プリペイドカード |
| US7254607B2 (en) * | 2000-03-30 | 2007-08-07 | United Devices, Inc. | Dynamic coordination and control of network connected devices for large-scale network site testing and associated architectures |
| US6954795B2 (en) * | 2000-04-05 | 2005-10-11 | Matsushita Electric Industrial Co., Ltd. | Transmission/reception system and method for data broadcast, and transmission apparatus for data broadcast |
| US7469405B2 (en) * | 2000-04-25 | 2008-12-23 | Kforce Inc. | System and method for scheduling execution of cross-platform computer processes |
| AUPQ867700A0 (en) * | 2000-07-10 | 2000-08-03 | Canon Kabushiki Kaisha | Delivering multimedia descriptions |
| US6934740B1 (en) * | 2000-09-19 | 2005-08-23 | 3Com Corporation | Method and apparatus for sharing common data objects among multiple applications in a client device |
| JP3646983B2 (ja) * | 2000-10-19 | 2005-05-11 | 株式会社ソニー・コンピュータエンタテインメント | 待ち順番表示方法、待ち順番表示方法のプログラム、待ち順番表示方法のプログラムが記録された記録媒体、及びコンテンツ配信システム |
| JP2002152265A (ja) * | 2000-11-15 | 2002-05-24 | Tadashi Yamamoto | 通信回線網の接続経路選択方法と装置及び該接続経路選択プログラムを記録した記録媒体 |
| JP4602535B2 (ja) * | 2000-11-17 | 2010-12-22 | 富士通株式会社 | スケジュール実行管理装置および管理方法 |
| US7065586B2 (en) * | 2000-12-22 | 2006-06-20 | Radiance Technologies, Inc. | System and method for scheduling and executing data transfers over a network |
| US7142508B2 (en) * | 2000-12-22 | 2006-11-28 | Radiance Technologies, Inc. | System and method for controlling data transfer rates on a network |
| US20050273514A1 (en) * | 2000-12-22 | 2005-12-08 | Ray Milkey | System and method for automated and optimized file transfers among devices in a network |
| JP3514246B2 (ja) * | 2001-03-30 | 2004-03-31 | ミノルタ株式会社 | 画像処理システム、サーバ、画像処理装置、画像処理装置管理方法、プログラム、記録媒体 |
| US6839564B2 (en) * | 2001-04-25 | 2005-01-04 | Nokia Corporation | Synchronization of database data |
| JP2002342097A (ja) * | 2001-05-17 | 2002-11-29 | Matsushita Electric Ind Co Ltd | タスク割当可能時間決定装置及びタスク割当可能時間決定方法 |
| US6996393B2 (en) * | 2001-08-31 | 2006-02-07 | Nokia Corporation | Mobile content delivery system |
| EP1324553A3 (fr) * | 2001-12-31 | 2006-03-22 | Alcatel Canada Inc. | Procédé et dispositif pour la planification et la maintenance d'événements utilisant une structure de calendrier |
| US7020710B2 (en) * | 2002-06-21 | 2006-03-28 | Thomson Licensing | Streaming media delivery on multicast networks for network and server bandwidth minimization and enhanced personalization |
| US7164919B2 (en) * | 2002-07-01 | 2007-01-16 | Qualcomm Incorporated | Scheduling of data transmission for terminals with variable scheduling delays |
-
2001
- 2001-08-31 FR FR0111330A patent/FR2829330B1/fr not_active Expired - Fee Related
-
2002
- 2002-09-02 JP JP2002257059A patent/JP2003196234A/ja active Pending
- 2002-09-03 US US10/232,405 patent/US20030055916A1/en not_active Abandoned
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5774479A (en) * | 1995-03-30 | 1998-06-30 | Motorola, Inc. | Method and system for remote procedure call via an unreliable communication channel using multiple retransmission timers |
| WO2000058900A1 (fr) * | 1999-03-31 | 2000-10-05 | The Chase Manhattan Bank | Systeme de gestion de fonds financiers et de conformite aux directives en matiere d'investissement de portefeuille |
Also Published As
| Publication number | Publication date |
|---|---|
| US20030055916A1 (en) | 2003-03-20 |
| JP2003196234A (ja) | 2003-07-11 |
| FR2829330B1 (fr) | 2003-11-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0715257B1 (fr) | Outil d'aide à la répartition de la charge d'une application répartie | |
| FR2857763A1 (fr) | Procede d'acces et de partage d'un document numerique dans un reseau de communication p2p | |
| EP2894872B1 (fr) | Procédé d'ordonnancement de tâches dans un réseau à courants porteurs en ligne | |
| FR2957700A1 (fr) | Procede, programme d'ordinateur et dispositif d'optimisation de chargement et de demarrage d'un systeme d'exploitation dans un systeme informatique via un reseau de communication | |
| FR2758681A1 (fr) | Allocation a une pluralite d'elements d'autorisations d'acces a une ressource partagee | |
| EP2955875B1 (fr) | Serveur, client et système de gestion d'un réseau d'interconnexion | |
| EP1422872B1 (fr) | Procédé et dispositif modulaire de traçage d'un message multimédia à travers un réseau de télécommunications | |
| FR2829330A1 (fr) | Procede de demande de reception du resultat d'execution d'une fonction a distance a une date predeterminee | |
| EP1897360B1 (fr) | Dispositif et procede pour gerer des credits de communication associes a l'utilisation de services par un terminal | |
| EP1187393A2 (fr) | Procédé et système de paiement d'opérations de transmission et/ou de services effectuées au sein d'un réseau de transmission de données par paquets | |
| EP2674860B1 (fr) | Procédé de traitement de données par un module de navigation | |
| FR2994782A1 (fr) | Procede et systeme d'execution de protocoles de chargement de donnees | |
| EP1578085B1 (fr) | Procédé et dispositif de téléchargement de données numériques sur un terminal après mesure du débit en réception pour le terminal | |
| FR2811098A1 (fr) | Procede et dispositif de transfert d'un document electronique dans un reseau de communication | |
| FR2854753A1 (fr) | Procede de distribution de documents numeriques multi-resolutions | |
| EP1829336A1 (fr) | Procede, systeme et moyen de distribution d'un colis de donnees a une pluralite d'ordinateurs repartis sur un ensemble de reseaux locaux distincts | |
| EP1494419B1 (fr) | Système de transmission de paramètres caractéristiques d'une session de communication d'un terminal vers un serveur distant | |
| EP1508237B1 (fr) | Protocole de communication entre un module d'application vocale et une plate-forme vocale dans un serveur vocal | |
| WO2017137314A1 (fr) | Procede de transmission de donnees dans une communication multi-chemin | |
| WO2009013440A1 (fr) | Procede d'echange de messages entre serveur de donnees de session et des services clients | |
| FR2816419A1 (fr) | Procede de repartition de charge entre serveurs d'un systeme informatique distribue | |
| EP2320623B1 (fr) | Procédé de fourniture d'un service | |
| WO2015145047A1 (fr) | Procédé de gestion d'une conférence impliquant une pluralité de dispositifs de traitement de données | |
| FR3079711A1 (fr) | Procede de gestion d'acces a un contenu numerique. | |
| EP1622339A1 (fr) | Procédé et dispositif de distinction de requêtes HTTP utilisateur |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |
Effective date: 20140430 |