Client/serveur en VB [Résolu]

Ouk18 19 Messages postés vendredi 5 novembre 2004Date d'inscription 26 janvier 2005 Dernière intervention - 21 janv. 2005 à 13:37 - Dernière réponse : crenaud76 4172 Messages postés mercredi 30 juillet 2003Date d'inscription 9 juin 2006 Dernière intervention
- 24 janv. 2005 à 08:34
Je me demandais si c'était possible. Et si oui, est ce possible de tenter de créé un prototipe sur une seul machine (en simulant un réseau ou autre astuce inimaginable).
Afficher la suite 

14 réponses

Meilleure réponse
cs_Jack 14010 Messages postés samedi 29 décembre 2001Date d'inscription 28 août 2015 Dernière intervention - 21 janv. 2005 à 14:22
3
Merci
Salut
Pour tester ton client serveur sur un même poste, il suffit de demander au client de se connecter sur l'adresse IP 127.0.0.1 qui est lui-même (adresse réservée)

Vala
Jack
NB : Je ne répondrai pas aux messages privés

Le savoir est la seule matière qui s'accroit quand on la partage. (Socrate)

Merci cs_Jack 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 72 internautes ce mois-ci

Teclis01 1423 Messages postés mardi 14 décembre 2004Date d'inscription 29 décembre 2012 Dernière intervention - 21 janv. 2005 à 13:44
0
Merci
Oui c'est possible !
j ai fait un client serveur en TCP .
Le serveur accepte les multi connections si tu as besoin d aide demande moi
Vas voir ma source ...
Neo.balastik 797 Messages postés jeudi 17 mai 2001Date d'inscription 5 mai 2009 Dernière intervention - 21 janv. 2005 à 16:24
0
Merci
Salut ;O)

J'ai toujours des doutes quand on me parle de serveur avec VB. VB n'étant pas multithreading, difficile de faire quelques de réellement convenable et d'exécuter des tâches dans des process différents. A moins de bricoler. Mais bon, on connait les limites du bricolage.

Ceci dit, j'adore VB6 !

Guy
crenaud76 4172 Messages postés mercredi 30 juillet 2003Date d'inscription 9 juin 2006 Dernière intervention - 21 janv. 2005 à 17:55
0
Merci
en quoi une appli serveru a-t-elle besoin de faire du multi-threading ? Pour des raisons de performance, certe ? mais à part cela, je vois pas !!

Christophe R
Neo.balastik 797 Messages postés jeudi 17 mai 2001Date d'inscription 5 mai 2009 Dernière intervention - 21 janv. 2005 à 18:17
0
Merci
Bien justement, qui dit serveur dit performance car traitements multiples.
L'application serveur devra traiter des demandes venant de plusieurs connexions.

Dans le cas d'une programmation en un seul process, les demandes devront attendre que la précédente soit traitée... Ce qui n'est pas idéal.

Guy
crenaud76 4172 Messages postés mercredi 30 juillet 2003Date d'inscription 9 juin 2006 Dernière intervention - 21 janv. 2005 à 23:38
0
Merci
D'accord avec toi, mais tout dépend de ce que doit faire ton serveur !! J'ai personnellement dev une appli client/serveur en VB6, et les clients ne se plaignent pas !! Tout dépend de ce que doit traiter le serveur (dans mon cas, juste de l'écriture dans un fichier), du nombre de client (plus de 400 pour mon cas tout de même), de la machine serveur (une Formule 1), et de la qualité du réseau (Wan sur LS 256Ko et Lan 10Mb/s). Reste à bien doser l'affaire !!
Ouk18 19 Messages postés vendredi 5 novembre 2004Date d'inscription 26 janvier 2005 Dernière intervention - 22 janv. 2005 à 13:16
0
Merci
Ok, alors si je doit pouvoir mettre plusieurs personnes simultanéement sur mon serveur, je laisse tomber VB, c bien sa ?
Neo.balastik 797 Messages postés jeudi 17 mai 2001Date d'inscription 5 mai 2009 Dernière intervention - 22 janv. 2005 à 13:44
0
Merci
En effet, tout dépend de ce que doit faire ton application serveur.
Je ne dis pas que VB soit impossible à utiliser, c'est selon le cas.

Mais je n'imagine pas programmer en VB une application serveur ayant de lourds traitements par utilisateurs connectés. Car comme je le disais précedemment, ce serait chacun à son tour et non simultanément. VB procédant de la sorte. Toutefois, il serait possible de palier à ce problème en créant des ActiveX EXE, ceux-ci étant dans un processus séparé du processus principal.

Imagine Oracle Serveur n'étant pas multithreading.... La folie ! Mais bon, VB peut suffir pour des traitements légers.

Bonne prog'

Guy
Ouk18 19 Messages postés vendredi 5 novembre 2004Date d'inscription 26 janvier 2005 Dernière intervention - 22 janv. 2005 à 16:46
0
Merci
Ok, g t sur la maquette d'un STR que je voulais mettre en MMO pour m'eclater ac qq potes, et peut etre plus apres. V finir ma maquette pour le fun et puis me mettre serieusement au java... Sa va etre cho.

Merci.
crenaud76 4172 Messages postés mercredi 30 juillet 2003Date d'inscription 9 juin 2006 Dernière intervention - 23 janv. 2005 à 00:50
0
Merci
Java n'est pas un modèle de rapidité !!
Neo.balastik 797 Messages postés jeudi 17 mai 2001Date d'inscription 5 mai 2009 Dernière intervention - 23 janv. 2005 à 11:08
0
Merci
En effet, je ne vois pas on plus Java come étant une solution idéale pour une application serveur. Java est un lourdeau avec sa virtual machine...

Guy
Ouk18 19 Messages postés vendredi 5 novembre 2004Date d'inscription 26 janvier 2005 Dernière intervention - 23 janv. 2005 à 12:01
0
Merci
Alors, qu'est ce ke vous me conseiler ? (Sa y'est, c reparti pour des mois d'apprentisage...)
Neo.balastik 797 Messages postés jeudi 17 mai 2001Date d'inscription 5 mai 2009 Dernière intervention - 23 janv. 2005 à 14:13
0
Merci
Au fait, je me demande si on a pas dépassé le cadre initial de ta question ?
Tente avec VB et essaye d'optimiser au mieux. Sinon, lance-toi dans VB.NET .

Guy
crenaud76 4172 Messages postés mercredi 30 juillet 2003Date d'inscription 9 juin 2006 Dernière intervention - 24 janv. 2005 à 08:34
0
Merci
VB.NET est aussi un modèle de lenteur !! Pour un code rapide et efficace, le plus efficace est le C/C++

Christophe R

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.