Question sur le resume.

Je suis entrein de me faire mon propre bot xdcc vu que je n'ai pas trouver mon bonheur parmis ceux que j'ai testé.
Je me demandais donc comment était calculé la position exacte de redémarrage d'un resume quand la personne à déjà reçu "n" octets du fichier.
Est ce qu'il demande un redémarrage à la position "n" ou à la position "n+1"? Est ce qu'il faut commencer à envoyer le fichier à la position demandé ou au niveau de l'octet suivant?


Je pose la question ici, par ce que j'ai le resume d'mirc qui merde complétement. J'ai créé un fichier de 10 octects nomé "test.txt" dans le répertoire de récupération d'mirc, ensuite, je suis passé par telnet pour déclancher un resume du fichier avec mirc comme receveur.
Mirc m'a alors répondus :
DCC RESUME "test.txt"

Comme vous pouvez le voir, il manque le numéro de port et la position à laquelle il est censé resumer le fichier. Est ce que vous sauriez d'où vient ce probléme et quel fichier je dois modifier pour le résoudre? J'utilises mirc en version 6.14 avec sysreset en version 2.53.

les ports sont indikés dans les options DCC qui sont elles meme dans les options de mirc (menu "view" ensuite "options" pour les options de mirc)

sinon le dcc c'est pas mon truc mais j'ai quand meme regarder dans l'aide et il est indiqué :

"Protocole Resume de DCC,

Utilisateur1 envoie le fichier.
Utilisateur 2 reçoit le fichier.

Pour initier un DCC Send, Utilisateur1 envoie :

PRIVMSG Utilisateur2 :DCC SEND nomdefichier adresseIP port tailledefichier

Normalement, si Utilisateur2 accepte la requête DCC Send, Utilisateur2 se connecte à l'adresse et au numéro de port donné par Utilisateur1 et le transfert de fichier commence.

Si Utilisateur2 choisit de résumer un transfert de fichier d'un fichier existant, la négociation suivante prend place :

Utilisateur2 envoie :

PRIVMSG Utilisateur1 :DCC RESUME nomdefichier port position

nomdefichier = le nom de fichier envoyé par Utilisateur1.
port = le numéro de port envoyé par Utilisateur1.
position = la taille actuelle du fichier que Utilisateur2 a.

Utilisateur1 répond alors :

PRIVMSG Utilisateur2 :DCC ACCEPT nomdefichier port position

C'est simplement la réponse par la même information que Utilsateur2 a envoyé comme renseignement.

A ce point, Utilisateur2 se connecte à l'adresse et le port de Utilisateur1 et le transfert commence à la position spécifiée.

Note : les nouvelles versions de mIRC ignorent actuellement le nom de fichier s'il est redondant si le port identifie uniquement la connexion. Cependant, pour rester compatible avec les mIRC plus vieux, mIRC envoie toujours un nom de fichier en tant que file.ext dans RESUME et ACCEPT.

jpeux pas t'en dire plus dsl

La doc mirc, je l'avais déjà lu.
Mais vu les test de resume avec mon bot comme client, je n'ai pas pu déterminé si on comence au niveau du dernier octet reçu ou au niveau du premier manquant. C'est certe un point de détail, mais c'est sufisant pour que le resume merde.

Comme mon mirc à moi à son resume qui ne marche pas, je peux pas faire de test plus évolué.


En tout cas, j'espéres que j'arriverais un jour à réparer le resume de mon mirc, ca sera beaucoup plus simple pour tester les mises à jour de mon bot.

J'ai oublier de préciser, mon bot n'est pas en mircscript mais en java (bot 100% autonome vu que nécessitant pas de programme irc extérieur).
C'est pour ça que je me poses des questions légérements différentes de celles habituelles et c'est pour ça que pour faire mon bot, j'ai besoin de réponses différentes de celles attendus par un utilisateur d'mirc. ;)

bah la reponse tombera pas du ciel ça c'est kler :')

Domage, la réponse ne tombera pas de ce forum non plus. :(

Heu, franchement je suis largué la!!
C koi un BOT
koment on fait pour trouver des channels
car j'ai un programme ki se telecharge mais pas en entier il se coupe!
merci