Forum Graph100

le jour ou des fonctions qui fonctionnent lol sortiront je suis sur que ca ira mieux !

ecoutez vous savez pas lire ou koi ?
c si simple en + !
c bien plus simple que els interruptions Dos courantes !
(seulement pour pc)
Ecoutez, je vais reflechir a un protocole commun (qui pourra etre utilise pour du transfert, chat, jeu en reseau..)
Il s'appellera Xlink, chaque programme qui voudra avoir des focntoons reseau se fera client Xlink
Par exemple pour DirXplor, il sera client Xlink avec les focntions :
-Envoid e fichiers
-Envoi de lecteurs
-Envoi de screen (fichier bmp en gros)
Et Flash100 integrera ce protocole Xlink pour :
-Envoyer/Rezcevoir des lecteurs, fichiers, screens
-Chatter
ERt par exemple le prog sur g100 de bugbug aura ce protocole Xlink pour envoyer des infos sur la caltos au client serveur Xlink

Voila
ce projet est embitieux mais aprés tt les prog pourraont communiquer ensemble !
Faut que je vois le type de synchronisation, la vitesse utilisée en standart..


Voila

ça permetterait aussi pas ke 2 joueurs, mais 4!

4 joueurs ?
en reponse a xth :
c juste un protocole, cad un protocole d'envoi de données, de checksum, mais on peut trés bien l'utiliser pour envoyer des paquets (comme le tcp/ip) car en afit pour le transfert, j'ai l'idée de faire des transferts par paquets, un paquet de 1octet d'ident+16octets+1 de checksum et voila, avec ça on peut par exemple revenir en arriere si un paquet etait corrompu, sauter directement a une position du fichier..
c'est trés simple (je vous fait du live la !) :
Paquet de la calc 1 a la calc 2 (par ex un fichier)
1er Octet :
bit 1 : paquet donnée
bit 2 : premier paquet
Bit 3 : Dernier paquet
bit 4 : Renvoi du paquet (si un paquet a été corrompu)
bit 5 : Presence d'un checksum
bit 6 : Taille de 16
bit 7 : taille de 8 (si aucun des 2 n'est a un, le paquet aura omme taille 1)
bit 8 : bit de papité du 1er octet
- les 8 ou 16 octets
- le byte de checksum
petet pour 16octet, regrouper par 2octet et indiquer leur parité sur un bit du checksum
Par ex, l'ensemble des 2 premiers octets a un nnombre pair de bits allumés donc le premier bit du checksum aura 1, ainsi de suite..
Aussi pour chaque paquet envoyé, il y aurra une reponse, et paril, un paquet
le paquet de reponse d'un fichier aura comme reponse :
-soit le paquet precedent ete corrompu
-soit une demande de fin d'envoi
-soit une demande de saut vers un autre endroit du fichier
-soit un octet d'acceptation (paquet ok)

ensuite, il faut definir le protocole de synchronisation
et la c plus complexe
Je sais pas si il faut definir un recepteur et un serveur (ça serai splus simple mais pas assez multimedia) ou que les deux soit pareil, et la bon ça serait le bordel
donc je me reponds a moi meme, non, c mieux de faire client serveur en sachant que chaque prog peut etre client ou serveur
voila
il faut que j'en reflechisse !

scan et envoi le sur mon mail que je regarde

moi aussi je bosse, sur le réseau entre G100 <-> G100 et G100 <-> PC (avec Flash100).
G regardé la doc de Whyp sur la communication, donc là je fais juste des tests avec le port de communication. Je ne fais que débuter.
Mais bon si Superna et X-thunder28, vous avez déjà un protocole en-tete et qui est bien, ca m'évitera de le faire, lol.

data66> le tuto de whyp est un peu périmé pour la communication  :!:
Va sur le site superNA

lol j'avait pas vu ce sujet (je vient presque jamais sur ce forum) bonne chance