[C#] [SQL] Architecture client-serveur
scoubidou944
Messages postés
714
Date d'inscription
mardi 22 avril 2003
Statut
Membre
Dernière intervention
19 janvier 2017
-
9 août 2005 à 20:08
scoubidou944 Messages postés 714 Date d'inscription mardi 22 avril 2003 Statut Membre Dernière intervention 19 janvier 2017 - 11 août 2005 à 12:40
scoubidou944 Messages postés 714 Date d'inscription mardi 22 avril 2003 Statut Membre Dernière intervention 19 janvier 2017 - 11 août 2005 à 12:40
A voir également:
- Client serveur base de données
- Base de données javascript - Conseils pratiques -Javascript
- Récupérer données json (javascript) - Conseils pratiques -Javascript
- Nomenclature base de données - Conseils pratiques -PHP
- Connexion base de données - Conseils pratiques -PHP
- Le jeu de sauvegarde contient la sauvegarde d'une base de données qui n'est pas la base de données - Forum SQL
7 réponses
Fildomen
Messages postés
805
Date d'inscription
jeudi 22 mai 2003
Statut
Membre
Dernière intervention
30 octobre 2010
9 août 2005 à 21:16
9 août 2005 à 21:16
trop simple, les client ne ferons rien dans le pc serveur, il vont communiquer leurs demande en utilisation une connexion tcp/client avec le serveur, qui va chercher dans la base et leur répondre, il ne faut qu'un réseau (local ou internet), c tt
YaoYao !!
1 + 1 = 10
YaoYao !!
1 + 1 = 10
scoubidou944
Messages postés
714
Date d'inscription
mardi 22 avril 2003
Statut
Membre
Dernière intervention
19 janvier 2017
9 août 2005 à 22:06
9 août 2005 à 22:06
jusque la je savais encore répondre...
----------------------------
C++ forever
C# amateur
----------------------------
C++ forever
C# amateur
SharpMao
Messages postés
1024
Date d'inscription
mardi 4 février 2003
Statut
Membre
Dernière intervention
7 juin 2010
69
10 août 2005 à 13:53
10 août 2005 à 13:53
Hello,
Il faut que le chemain vers la base de données comprenne le nom du serveur. Sauf erreur, ça doit donner quelques chose comme ça :
[file://ServerName/C:/PathToMdbFile.mdb \\ServerName\C:\PathToMdbFile.mdb]
Amicalement, SharpMao
Il faut que le chemain vers la base de données comprenne le nom du serveur. Sauf erreur, ça doit donner quelques chose comme ça :
[file://ServerName/C:/PathToMdbFile.mdb \\ServerName\C:\PathToMdbFile.mdb]
Amicalement, SharpMao
sebmafate
Messages postés
4936
Date d'inscription
lundi 17 février 2003
Statut
Membre
Dernière intervention
14 février 2014
37
10 août 2005 à 15:04
10 août 2005 à 15:04
il n'est pas valide ton chemain SharpMao...
moi je suis partisan d'une solution 3 tiers...
- Serveur qui centralise les demandes
- Base de données accessible uniquement par le servuer
- Clients qui se connectent au serveur
La question est de savoir comment faire pour le serveur ? Quelle techno utiliser ?
- Webservice ?
- .NET Remoting ?
- Socket ?
à toi de voir...
<HR>
Sébastien FERRAND
Blog : http://blogs.developpeur.org/sebmafate
moi je suis partisan d'une solution 3 tiers...
- Serveur qui centralise les demandes
- Base de données accessible uniquement par le servuer
- Clients qui se connectent au serveur
La question est de savoir comment faire pour le serveur ? Quelle techno utiliser ?
- Webservice ?
- .NET Remoting ?
- Socket ?
à toi de voir...
<HR>
Sébastien FERRAND
Blog : http://blogs.developpeur.org/sebmafate
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
SharpMao
Messages postés
1024
Date d'inscription
mardi 4 février 2003
Statut
Membre
Dernière intervention
7 juin 2010
69
10 août 2005 à 16:13
10 août 2005 à 16:13
Hello,
En efet, ta solution est plus propre.
Par contre, la mienne marche, a un détail près :
[file://ServerName/C$/PathToMdbFile.mdb \\ServerName\C$\PathToMdbFile.mdb].
En effet, que ce soit avec Win 2000 ou Win XP, la racine des lecteurs est partagée par défaut, mais cachée ($).
En mettant l'accès ave le dollars, on peut acéder à n'importe quel disque réseau.
Autrement, on peut également partager juste le dossier contenant la base de données.
Exemple : Si le chemin vers la base de données est, sur le serveur TotoServer, C:\AAA\BBB\Base.mdb.
Faire un clic droit sur le dossier BBB et choisir propriétés.
Dans l'onglet partage, cliquer sur le radiobutton "Partager ce dossier", et mettre un nom de partage (Ex : CCC)
Si le nom de partage se termine par $, il ne sera pas visible par quelqu'un qui explore le réseau.
Par contre, en mettant Data Source="[file://TotoServer/CCC$/Base.mdb \\TotoServer\CCC$\Base.mdb], ça devrait marcher.
Pour plus de renseignement sur le partage de dossiers
Amicalement, SharpMao
En efet, ta solution est plus propre.
Par contre, la mienne marche, a un détail près :
[file://ServerName/C$/PathToMdbFile.mdb \\ServerName\C$\PathToMdbFile.mdb].
En effet, que ce soit avec Win 2000 ou Win XP, la racine des lecteurs est partagée par défaut, mais cachée ($).
En mettant l'accès ave le dollars, on peut acéder à n'importe quel disque réseau.
Autrement, on peut également partager juste le dossier contenant la base de données.
Exemple : Si le chemin vers la base de données est, sur le serveur TotoServer, C:\AAA\BBB\Base.mdb.
Faire un clic droit sur le dossier BBB et choisir propriétés.
Dans l'onglet partage, cliquer sur le radiobutton "Partager ce dossier", et mettre un nom de partage (Ex : CCC)
Si le nom de partage se termine par $, il ne sera pas visible par quelqu'un qui explore le réseau.
Par contre, en mettant Data Source="[file://TotoServer/CCC$/Base.mdb \\TotoServer\CCC$\Base.mdb], ça devrait marcher.
Pour plus de renseignement sur le partage de dossiers
Amicalement, SharpMao
mythic_kruger
Messages postés
241
Date d'inscription
jeudi 8 janvier 2004
Statut
Membre
Dernière intervention
10 novembre 2005
11 août 2005 à 12:20
11 août 2005 à 12:20
L'accès distant suppose dans tous les cas un protocole, un serveur, un port, et une ressource:
protocol://hostname:port/ressource
Exemple http port 80 signifie qu'on a un serveur web avec l'intention de lui
envoyer des requêtes avec un navigateur (ou autre user-agent), qui transmet
sa requête HTTP au serveur, dont le système
HTTP (Apache, IIS) transmet les commandes à une interface CGI (ASP,
Perl) qui s'occupe d'accéder à la base de donnée par ODBC avec ou sans
DSN (Nom de Source de Données, qui se configure dans les outils
d'administration).
C'est le cas de figure "web" avec ASP qui est à l'aise pour ces tâches.
Or, d'après le schéma de l'URI, si je veux passer en UDP par le port
21547, je peux à condition de programmer le système HTTP "qui fait
office de standardiste" pour citer Jojo le pote à Toto. C'est la
solution la plus longue à déployer, qui plus est le protocole de
conversation est à définir si on veut se passer du protocole HTTP, en d'autres termes
ne pas réécrire un serveur qui se complie au HTTP.
C'est faisable avec le .NET Remoting (remplace DCOM) en C#.
Le .NET Remoting permet d'envoyer des objets à travers le réseau, par
HTTP (pour réseau LAN ou WAN), TCP (plutôt LAN) et SMTP. Par défaut, le
channel HTTP utilise le format SOAP pour encoder les données transmises
(SOAP est basé sur le XML).
D'abord on crée l'objet télécommandé: monObjet.dll . Il contiendra le code ADO.
Compilé avec la référence /r:System.Runtime.Remoting.dll
Puis le serveur, qui tournera bien en *tousse* service windows.
using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;
Le serveur ouvre un channel au protocole et port désirés, puis enregistre l'objet télécommandé.
Le code du client sélectionne le channel de l'objet, enregistre le channel, puis crée
une nouvelle instance du remote object (et c'est là qu'on retrouve l'URI "tcp://serveur:8085/monObjet.dll"
3 lignes de code côté client: le framework prend en charge le reste.
Troisième méthode, à l'ancienne-brutal: avec les sockets de la fac de
Berkeley (TCP ou UDP) telle une application Client/Serveur classique!
(ceci dit en passant chaque université aux states est spécialisée dans
un secteur
nous on suit enfin on essaie).
Le serveur exécute les commandes qu'on lui passe et renvoie les
données. Simple? lol. Un simple byte transmis au serveur permettrait
d'effectuer plétore d'actions, Fascinant non? Toi c'est la couche
ADO qui t'intéresse pour le serveur.
Et sans DSN puisque la base n'est généralement pas très loin de l'exe (au moins sur la
un partition locale, pour des raisons de performances). Pour streaming chargés opter pour les datagrammes UDP.
Voilà ça fait trois méthodes (il en existe d'autres).
Scoubi pour répondre à ta question sur les routeurs/ports: il faut
forwarder les ports si la base est sur une machine derrière une
passerelle.
protocol://hostname:port/ressource
Exemple http port 80 signifie qu'on a un serveur web avec l'intention de lui
envoyer des requêtes avec un navigateur (ou autre user-agent), qui transmet
sa requête HTTP au serveur, dont le système
HTTP (Apache, IIS) transmet les commandes à une interface CGI (ASP,
Perl) qui s'occupe d'accéder à la base de donnée par ODBC avec ou sans
DSN (Nom de Source de Données, qui se configure dans les outils
d'administration).
C'est le cas de figure "web" avec ASP qui est à l'aise pour ces tâches.
Or, d'après le schéma de l'URI, si je veux passer en UDP par le port
21547, je peux à condition de programmer le système HTTP "qui fait
office de standardiste" pour citer Jojo le pote à Toto. C'est la
solution la plus longue à déployer, qui plus est le protocole de
conversation est à définir si on veut se passer du protocole HTTP, en d'autres termes
ne pas réécrire un serveur qui se complie au HTTP.
C'est faisable avec le .NET Remoting (remplace DCOM) en C#.
Le .NET Remoting permet d'envoyer des objets à travers le réseau, par
HTTP (pour réseau LAN ou WAN), TCP (plutôt LAN) et SMTP. Par défaut, le
channel HTTP utilise le format SOAP pour encoder les données transmises
(SOAP est basé sur le XML).
D'abord on crée l'objet télécommandé: monObjet.dll . Il contiendra le code ADO.
Compilé avec la référence /r:System.Runtime.Remoting.dll
Puis le serveur, qui tournera bien en *tousse* service windows.
using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;
Le serveur ouvre un channel au protocole et port désirés, puis enregistre l'objet télécommandé.
Le code du client sélectionne le channel de l'objet, enregistre le channel, puis crée
une nouvelle instance du remote object (et c'est là qu'on retrouve l'URI "tcp://serveur:8085/monObjet.dll"
3 lignes de code côté client: le framework prend en charge le reste.
Troisième méthode, à l'ancienne-brutal: avec les sockets de la fac de
Berkeley (TCP ou UDP) telle une application Client/Serveur classique!
(ceci dit en passant chaque université aux states est spécialisée dans
un secteur
nous on suit enfin on essaie).
Le serveur exécute les commandes qu'on lui passe et renvoie les
données. Simple? lol. Un simple byte transmis au serveur permettrait
d'effectuer plétore d'actions, Fascinant non? Toi c'est la couche
ADO qui t'intéresse pour le serveur.
Et sans DSN puisque la base n'est généralement pas très loin de l'exe (au moins sur la
un partition locale, pour des raisons de performances). Pour streaming chargés opter pour les datagrammes UDP.
Voilà ça fait trois méthodes (il en existe d'autres).
Scoubi pour répondre à ta question sur les routeurs/ports: il faut
forwarder les ports si la base est sur une machine derrière une
passerelle.
scoubidou944
Messages postés
714
Date d'inscription
mardi 22 avril 2003
Statut
Membre
Dernière intervention
19 janvier 2017
11 août 2005 à 12:40
11 août 2005 à 12:40
houla vive l'usine à gaz... :( en tout cas merci d'avoir pris le tps d'écrire un tel pavé ;p
me reste plus qu'a tester cela ;p
----------------------------
C++ forever
C# amateur
me reste plus qu'a tester cela ;p
----------------------------
C++ forever
C# amateur
