scoubidou944
Messages postés714Date d'inscriptionmardi 22 avril 2003StatutMembreDernière intervention19 janvier 2017
-
9 août 2005 à 20:08
scoubidou944
Messages postés714Date d'inscriptionmardi 22 avril 2003StatutMembreDernière intervention19 janvier 2017
-
11 août 2005 à 12:40
histoire de faire des tests, voici l'exercice (d'ailleurs, pk y'a pas une section exercice sur le site pour qu'on puisse progresser chacun à son niveau )
réseau local
serveur Windows XP Pro contenant une base Access
clients Windows avec .NET framework installé
Le but : que le client puisse aller pecher des info dans la base sur le serveur.
Questions :
- que faut-il installer sur le serveur ? IIS ? Access? .NET ?
- pour l'acès à la base il faut p-e un dossier partagé ? Comment on gère la sécurité à ce niveau
- qql'1 a-t-il un tuto pouvant servir d'architecture ?
rahlalal que ferait-on sans vous ;p
----------------------------
C++ forever
C# amateur
Fildomen
Messages postés805Date d'inscriptionjeudi 22 mai 2003StatutMembreDernière intervention30 octobre 2010 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
sebmafate
Messages postés4936Date d'inscriptionlundi 17 février 2003StatutMembreDernière intervention14 février 201437 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 ?
SharpMao
Messages postés1024Date d'inscriptionmardi 4 février 2003StatutMembreDernière intervention 7 juin 201069 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.
mythic_kruger
Messages postés241Date d'inscriptionjeudi 8 janvier 2004StatutMembreDernière intervention10 novembre 2005 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.