Salut,
 
Comment écrire un code client en C++ pour ouvrir et lire un fichier texte situé sur un serveur distant (sans rapatrier ce fichier)?
Quels sont les protocoles généralement utilisés et quelles sont les méthodes appropriées ?
 
Si quelqu'un avait un exemple simple pour me montrer comment faire en sorte que le fopen (de ifstream) du code client comprenne qu'il faut ouvrir un fichier sur serveur...
 
Merci,
 
Un vrai débutant

Tu passes par un montage NFS

 
Cela permet de n'avoir qu'une lettre pour identifier le serveur, c'est cela ?
Si oui, je suis ok, cela marche.
 
Mais précisément je cherche la solution sans montage...
 
Merci quand même
;-)

ftp

ftp ?  
C'est un peu court...Pour que je puisse comprendre...
Quelqu'un sait-il comment faire un code client en C++ pour OUVRIR (puis lire) un fichier texte distant ?
En utilisant ftp comme protocole pourquoi pas...??
 
Merci

google : http://www.cppfrance.com/gma/ftp

Tu ne peux pas ouvrir directement un fichier sur un serveur distant, sauf si le système de fichiers est monté en local d'une manière ou d'une autre (par exemple à l'aide d'un montage NFS).
La seule solution vraiment viable est de récupérer le fichier et de le traiter en local. D'où la réponse de Taz : ftp.

Quant à savoir ce que c'est : Google

NFS ou CIFS amha

Je vois pas non plus pourquoi il y aurait un problème avec ftp, à part rapatrier le fichier pour le lire (à la différence des deux premiers cités).

En revanche, si c'est pour coder un client from scratch, vaudrait mieux jouer avec des sockets et du ftp (et utiliser fdopen à la place de fopen) que de se lancer à fond les manettes dans les RPC, ca pourrait être long et douloureux

Edit: ah oui et probablement autre possibilité: webdav.

 
Précisément,
 
Je pense qu'il me faut utiliser des sockets (après avoir lu plusieurs choses sur le net...). Je ne savais par contre pas comment ouvrir le fichier distant...Je regarde la piste fdopen...Merci.
 
PS : dommage que je n'ai pu trouver un exemple (court) disponible sur le net...

Un example sur le net? Sérieux c'est la base des socket, cherche mieux.

Fait à l'arrache, un truc dans le genre (minus les erreurs de syntaxe hein, pas taper )

Socket TCP:

Merci mais j'avais effectivement déjà pu lire ce type de code, sauf que je ne comprends toujours pas comment on passe l'info concernant le nom du fichier à ouvrir (puis lire)...
Dans l'exmple, on construit la socket fds pour communiquer avec le serveur et on comprend qu'il y a ouverture d'un fichier grâce à fdopen...Mais quel fichier ?? fds pointe bien sur l'IP du serveur (getadrrinfo) mais où dit-on au client d'aller lire le fichier \users\toto.txt sur ce serveur ??
 
J'aurai envie d'écrire un truc du style stream=fopen("\users\toto.txt", "r" )...mais stream est déjà associé à la socket...
 
???

Houla, je pense qu'on va (re)commencer par le commencement alors.
 
socket: http://www.laissus.fr/cours/node18.html
 
Tout ce qui est protocole (NFS, FTP, HTTP) sont plus haut niveau que TCP, lui même basé sur IP. Le socket ne concerne que TCP/IP, c'est à toi de faire le protocole pour ouvrir ton fichier distant. Soit tu le fais toi même (client + serveur à coder), soit tu te greffes par dessus un protcole existant, et il ne te reste plus que le client à modifier légèrement pour faire ce que tu veux.
 
Par exemple, pour ftp, tu ouvres le socket, tu récupères le fichier (get...) tu le mappes en mémoire (mmap) tu travailles dessus, et tu le renvoies au serveur (put).
 
Oui, y'a du code à taper...
 
Personnellement, j'obterais pour des partages réseau genre NFS/CIFS, ils ferront aussi bien, et tu travailles sur le fichier directement au travers du partage monté.
 
Question de choix.

Sans faire de code côté serveur et sans montage type NFS, il faut récupérer(get...) le fichier avant de travailler dessus...Il est rapatrié côté client ?

Oui. Encore une fois, tu ne peux pas ouvrir un fichier directement s'il se trouve sur un serveur distant, sauf s'il est monté d'une manière ou d'une autre de manière locale.
Si tu ne passes pas par un NFS quelconque, tu dois rapatrier le fichier.

Sans faire de code côté serveur et sans montage type NFS,il faut donc avoir de l'espace disque disponible côté client...C'est nul !!

Attends. Imagine maintenant le cas inverse : tu peux ouvrir tous les fichiers que tu veux directement sur le serveur que tu veux. Et pose-toi ensuite la question suivante : est-ce que ça te plairait de savoir, lorsque tu te connectes sur internet, que tout le monde potentiellement peut accéder à tes fichiers directement et les lire ou les modifier ?

edit : hmm, j'ai sans doute répondu à côté de la plaque

Si tu avais lu ce que j'ai marqué au dessus, rien ne t'empeche de mapper une zone pour écrire dedans. Au lieu d'espace disque, c'est en ram que tu travailles.

man mmap.

Y'a pas que ca en plus: au niveau local, le noyau peut gérer les accès concurrentiels avec des verrous, qu'on peut mettre dans le code avec la libpthread ou des semaphores.

Par réseau, ca va être galère à gérer

HTTP aussi, dav, toussa.
 
On y peut quoi : l'informatique c'est pas magique.