MESSENGER -> GESTION DES CONNECTES PAR SERVEUR ASP, TRANSFERT DE FICHIER ETC
cs_FAS
Messages postés
88
Date d'inscription
vendredi 26 avril 2002
Statut
Membre
Dernière intervention
24 février 2006
-
17 déc. 2002 à 09:00
celiphane Messages postés 466 Date d'inscription samedi 16 février 2002 Statut Membre Dernière intervention 20 avril 2007 - 18 févr. 2004 à 17:37
celiphane Messages postés 466 Date d'inscription samedi 16 février 2002 Statut Membre Dernière intervention 20 avril 2007 - 18 févr. 2004 à 17:37
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/5352-messenger-gt-gestion-des-connectes-par-serveur-asp-transfert-de-fichier-etc
https://codes-sources.commentcamarche.net/source/5352-messenger-gt-gestion-des-connectes-par-serveur-asp-transfert-de-fichier-etc
18 févr. 2004 à 17:37
Voici pour tes questions :
"Est-ce la seule méthode pour imposer à winsock une trame de 2 ko?"
> à ma connaissance oui. Quoi qu'il en soit, tu peux envoyer des trames plus longues, par exemple 2 Mo ! Mais Winsock a sa propre limite et va de lui-même découpé ta trame, elle arrivera en plusieurs morceaux, et je préfère de loin gérer moi-même le découpage. En ce qui concerne sa propre limite pour son découpage, je ne connais pas la valeur... peut-être 8196 octets.
"c'est comment se fait-il que l'instruction get reprend la lecture au bon endroit "
> imagine toi 2 minutes dans la peau d'un parfait abruti qui désire lire le contenu d'un fichier TXT dans le blocnotes, et qui pour lire, place le curseur de blocnote à la 1ère lettre, puis lis les X premières lettres et avance d'autant le curseur et ainsi de suite...... c'est comme ça que s'opère la lecture d'un fichier ! Sont traités les octets sous le curseur, à l'occasion nommé pointeur, qui avance au fil des octets lus. On dit qu'il "consomme" les octets.
"Est-ce que ça vaut le coup de se prendre un peu la tête ou est-ce qu'avec des string ça passe quoiqu'il en soit ?"
> Oui, ça passera toujours quoi qu'il en soit. Si il est coutume de manipuler les données brutes (binaire) avec des buffer de bytes (tableau d'octets) c'est parceque ce type d'accès est plus rapide pour faire des opérations. Dans le cas de notre transfert, ça ne change rien. Un octet est un octet, "ABC" vaut [65,66,67] et voilà tout.
@+
Celiphane
18 févr. 2004 à 15:17
Cette source m'a intéressé pour le système de téléchargement de fichier. J'espère que tu pourras m'éclaircir un peu.
Il y a deux choses que je comprends mal...
Quand tu lis le fichier à envoyer avec get, tu le stock dans une variable string de 2 ko et tu l'envoi au client puis tu attends la réponse du même client pour continuer l'envoi avec une seconde trame de 2 ko etc. sauf pour la dernière trame pour laquelle on dimensionne une nouvelle string(c bien ça?)
Donc on est sur d'envoyer des trames de 2 ko (pas plus) avec le winsock... Est-ce la seule méthode pour imposer à winsock une trame de 2 ko?
De plus un truc je pige ne pas c'est comment se fait-il que l'instruction get reprend la lecture au bon endroit du fichier à envoyer?
Mais bon sinon ça fonctionne... et même bien. Des fichiers de plus de 100 Mo, des .exe, transmis à l'octet près. ! Et le système de question réponse (j'ai n'ai pas tout pigé encore mais je vais décortiquer le code) est vraiment excellent !
Autre chose,
J’ai lu dans MSDN qu'il valait mieux manipulé les fichiers binaires (c'est bien des .exe par exemple?) avec des variables de type byte et des tableaux. J'ai essayé mais évidement ça ne fonctionne pas (je suis débutant de chez débutant aussi... ).J’ai des difficultés à dimensionner les variables/tableaux de type byte... qu'en penses-tu? Est-ce que ça vaut le coup de se prendre un peu la tête ou est-ce qu'avec des string ça passe quoiqu'il en soit ?
Merci de ton aide de toutes façons. et bravo aussi....!
14 mai 2003 à 01:36
en ce qui concerne ton pb, sache de prime abord que le prog fonctionne "normalement" puisqu'il a tourné qq semaines sur un réseau local, (cependant la méthode qu'il emploie n'est surement pas un modele du genre m'enfin :) ), mais cette allégation ne va pas résoudre ton pb.
A mon humble avis, la solution devrait se trouver sur la facon ou ton serveur Asp interprete... l'asp !
Je ne vois que ca, puisque ca passe ailleurs ! Je ne dis pas qu'il l'interprete mal, non, mais qu'il doit surement voir qq trucs différement, peut etre parcequ'il est pas ou trop à jour !
Trifouille le script dans ce sens et bonne chance !
13 mai 2003 à 22:05
On Error Resume Next Explained
This four word combination is used to tell the server to resume the next line of code if it finds an error. The situations you would want to use this in is when you are writing your own error trapping code and you want to display your error codes, not the ASP default ones.
Syntax:
Place "On Error Resume Next" in your code where you want the program flow to continue after it encounters an error. It is usually placed at the top of each page. *
By: Jared Stauffer
* Brinkster requires the use of "On Error GoTo 0" and the checking of the err object whenever you are using "On Error Resume Next". The use of the "On Error Resume Next" directive in combination with database connections, can result in server hang-ups and other server problems.
Si qqun a une solution (une modif du script) qu'il fasse un petit signe ca serais sympa !!! et pour ceux que ca interesse l'hebergeur asp gratos est
http://www.brinkster.com/
alé a+ et bonne continuation a tous !!!
ps: il est génial ce prog !!! merci !
14 janv. 2003 à 11:54
merci et bonne continuation...
(ps n'en faites qd mm pas trop !) ;)
13 janv. 2003 à 21:51
D'abord félicitation celiphane pour ce code et les autres. Je t'admire, tu es un champion.
Pour ceux que ça interesse, je suis en train de terminer (finioler) un petit prog VB de messagerie instantanée avec une interface PHP sur un serveur de page Perso et ça marche nickel. Ce prog est un peu comme celui de Celiphane mais en moins pro car je déébute en VB.
Envoyez moi un mail pour avoir l'interface PHP.
23 déc. 2002 à 14:27
sinon bon prog
19 déc. 2002 à 16:05
Merci
18 déc. 2002 à 14:14
17 déc. 2002 à 21:54
malheureusement, je ne sais pas programmer en PHP :
"BOU LA HONTE HO LE GROS NUL PFFF QUEL NAZE"
oui merci merci, merci bcp ! ;)
Libre à vous de convertir !
Tchao @+
17 déc. 2002 à 19:24
A quand la conversion ?
a+
17 déc. 2002 à 09:00