En effet, on a tout fait pour faciliter la configuration et implémenté l'UPnP (NATPMP à venir) mais dans la plupart des cas il faut configurer le routeur.
Nous reflechissons à une solution alternative, un genre de service minimum, par proxy en cas d'absence de redirection mais il va falloir attendre encore un peu!
En fait les performances dépendent surtout du mode de connection utilisé. Transfert utilise une connection directe qui a pour avantage la vitesse et pour inconvénient d'être accessible depuis internet (firewall, NAT configuré), la plupart des logiciel de messageries implémentent un transfert de fichier par proxy (un serveur fais le relais entre 2 clients) ce qui est exactement l'opposé.
Sinon la difference entre SIP et Jabber si je ne m'abuse c'est que SIP est optimisé pour des flux de données continus (VoIP) ou la stabilité prime sur la perte d'information. Et Jabber pour les données de type texte...
J'espere ne pas m'attirer les foudres des puristes...
Apres discussion il semble qu'un portage sur le protocole Jabber est envisageable. Nous voulons adopter une politique d'ouverture pour faciliter l'utilisation et la promotion du logiciel. Du coup l'utilisation de Jabber ouvrirait des portes vers d'autres services qui l'utilise.
Donc ce n'est pas un projet d'études, mais au départ, nous ne pensions pas distribuer le logiciel. C'est pourquoi les commentaires sont en francais et que nous n'avons pas utilisé ce genre de librairie.
Ton post soulève à nouveau ces questions et nous allons y réfléchir. Apache MINA à l'air très complet, et comme nous commençons à vouloir implémenter des fonctionnalités qu'il supporte ça nous intéresse beaucoup.
Merci pour ce message très instructif, pour l'UI qui rame, une option est dispo dans "configuration" pour enlever certains effets ;)
Même en étant bidirectionnel, il faut établir la connexion au départ. Donc si quelqu'un veut se connecter a vous, il faut que le routeur vous transmette les paquets. Tout simplement!
La vitesse de transfert dépends des vitesses d'upload et de download des 2 corespondants. Pour vous donner une idée, avec une connection adsl classique on peut avoir des taux de 150ko/s
Pour le moment les communications ne sont pas cryptées, on y pense, cependant les communications sont directes entre les utilisateurs, l'information ne transite pas sur un serveur. Le cryptae est important pour vous? (simple sondage perso)
5 fautes? Je ne les vois pas ça doit être gravé dans ma tête... Merci de me les donner afin que je corrige vite, avant que plus de personnes ne les voient... :$
Pourtant nous avons un testeur sous MacOSX qui n'a aucun problème. Il a peut être le bon processeur.
Pour ma part sous linux et windows azureus fonctionnent en Java 6.0...
Enfin le débat n'est pas la, on peut en effet détailler les informations de Java dans l'aide, on y pense. Merci pour ces informations et désolé que vous ne puissiez pas utiliser Transfert, espérons que Sun publie une version de Java 6 pour votre architecture...
Je ne prétends pas que la connection sera plus rapide que sur un serveur FTP, même si le protocole est plus leger.
Un serveur FTP mets à disposition des fichiers à des utilisateurs, la on choisis d'envoyer un fichier une fois à un destinataire, le principe est different. La ou Transfert est plus rapide, c'est par rapport à un échange qui transite sur un serveur tiers, on uploade sur un serveur puis le destinataire downloade. C'est le cas dans certaines applications.
Transfert implémente l'UPnP pour le forwarding des ports, l'implémentation de NATPMP est envisagée, mais on manque de testeurs pour cette fonctionalité. Le fait d'utiliser TCP nous empeche d'utiliser les astuces de type STUN TURN ICE, mais ces méthodes vont à l'encontre des systèmes de sécurité...
Le transfert de fichier est bien documenté mais, aujourd'hui, si un novice veut envoyer 30Mo de données à quelqu'un, il ne s'en sort pas (j'en ai vu plus d'un). Les méthodes existantes ne peuvent pas abstraire les concepts de clients serveur, IP, port, etc... C'est ce que Transfert essaie de faire! En fait plutôt que de nous battre sur la légitimité de notre protocole, discutons d'un remplaçant à celui ci. Nous avons besoin d'un protocole léger, qui permette de transférer des fichiers à la demande (sans partager), d'identifier ses utilisateurs ainsi que des relations entre eux et de chatter (même si on peux utilier un autre protocole comme Jabber pour ca). Et le top, il faudrai que le serveur centralisé (si besoin) tourne sur un serveur LAMP (gratuit chez tuxfamily). Connais tu un tel protocole?
La création de compte sert a gérer la liste des contacts et à s'identifier auprès des autres utilisateurs, le fait d'afficher une adresse IP en rebuterai surement plus d'un.
En fait le serveur sert à faire la correspondance entre identifiant et IP + Port, et à gérer la liste des contacts, rien d'autre!
Non le protocole n'est pas bittorent, la raison en est simple, le but du protocole de transfert est de communiquer entre deux postes et non de diffuser largement un fichier, ce protocole n'est donc pas adapté pour cette utilisation. Le protocole n'est pas propriétaire et peut être repris dans d'autres applications, si le besoin s'en fait sentir nous pourrons produire une documentation à cet effet (notre protocole étant très simple)
Je suis tout à fait d'accord sur le besoin de convergence dans ce genre d'applis mais nous n'avons pas trouvé de protocole standardisé qui nous corresponde, on peut rêver que les prochaines applis utiliserons celui la!
Pour répondre, oui c'est encore une appli à laisser tourner sur le poste mais ponctuellement ça peut être très utile, notamment pour les néophytes, pour envoyer de gros fichiers persos en direct simplement et à des taux de transfert corrects.
Si l'appli vous plaît utilisez la et faite lui de la pub, on manque cruellement d'utilisateurs (même si cette annonce nous à fait progressé de 40% en 1 jours!!!)
Si vous avez des suggestions ou des questions je serai ravi de répondre.
Pour info, je suis l'un des 2 développeur de ce projet, on est étudiant en informatique en stage de fin d'études... (Je suis donc partial il faut le savoir)
[^] # Re: NAT
Posté par yciabaud . En réponse à la dépêche Transfert: Echange de fichiers rapide et multiplateformes. Évalué à 1.
Nous reflechissons à une solution alternative, un genre de service minimum, par proxy en cas d'absence de redirection mais il va falloir attendre encore un peu!
[^] # Re: Mon avis
Posté par yciabaud . En réponse à la dépêche Transfert: Echange de fichiers rapide et multiplateformes. Évalué à 1.
Sinon la difference entre SIP et Jabber si je ne m'abuse c'est que SIP est optimisé pour des flux de données continus (VoIP) ou la stabilité prime sur la perte d'information. Et Jabber pour les données de type texte...
J'espere ne pas m'attirer les foudres des puristes...
[^] # Re: Mon avis
Posté par yciabaud . En réponse à la dépêche Transfert: Echange de fichiers rapide et multiplateformes. Évalué à 2.
[^] # Re: Mon avis
Posté par yciabaud . En réponse à la dépêche Transfert: Echange de fichiers rapide et multiplateformes. Évalué à 0.
[^] # Re: code
Posté par yciabaud . En réponse à la dépêche Transfert: Echange de fichiers rapide et multiplateformes. Évalué à 2.
Ton post soulève à nouveau ces questions et nous allons y réfléchir. Apache MINA à l'air très complet, et comme nous commençons à vouloir implémenter des fonctionnalités qu'il supporte ça nous intéresse beaucoup.
Merci pour ce message très instructif, pour l'UI qui rame, une option est dispo dans "configuration" pour enlever certains effets ;)
[^] # Re: Fonctionnalités futures ?
Posté par yciabaud . En réponse à la dépêche Transfert: Echange de fichiers rapide et multiplateformes. Évalué à 1.
Nous envisageons des connections avec des plateformes sociales sur internet, des configuration automatiques de routeur etc...
Mais si vous avez des idées, je serai curieux de les connaitre et put etre nous les integrerons!
[^] # Re: Questions
Posté par yciabaud . En réponse à la dépêche Transfert: Echange de fichiers rapide et multiplateformes. Évalué à 2.
[^] # Re: Mon avis
Posté par yciabaud . En réponse à la dépêche Transfert: Echange de fichiers rapide et multiplateformes. Évalué à 1.
Pour le moment les communications ne sont pas cryptées, on y pense, cependant les communications sont directes entre les utilisateurs, l'information ne transite pas sur un serveur. Le cryptae est important pour vous? (simple sondage perso)
5 fautes? Je ne les vois pas ça doit être gravé dans ma tête... Merci de me les donner afin que je corrige vite, avant que plus de personnes ne les voient... :$
[^] # Re: Java 6 et le Mac ...
Posté par yciabaud . En réponse à la dépêche Transfert: Echange de fichiers rapide et multiplateformes. Évalué à 1.
Pour ma part sous linux et windows azureus fonctionnent en Java 6.0...
Enfin le débat n'est pas la, on peut en effet détailler les informations de Java dans l'aide, on y pense. Merci pour ces informations et désolé que vous ne puissiez pas utiliser Transfert, espérons que Sun publie une version de Java 6 pour votre architecture...
[^] # Re: Questions
Posté par yciabaud . En réponse à la dépêche Transfert: Echange de fichiers rapide et multiplateformes. Évalué à 3.
Un serveur FTP mets à disposition des fichiers à des utilisateurs, la on choisis d'envoyer un fichier une fois à un destinataire, le principe est different. La ou Transfert est plus rapide, c'est par rapport à un échange qui transite sur un serveur tiers, on uploade sur un serveur puis le destinataire downloade. C'est le cas dans certaines applications.
Transfert implémente l'UPnP pour le forwarding des ports, l'implémentation de NATPMP est envisagée, mais on manque de testeurs pour cette fonctionalité. Le fait d'utiliser TCP nous empeche d'utiliser les astuces de type STUN TURN ICE, mais ces méthodes vont à l'encontre des systèmes de sécurité...
Le transfert de fichier est bien documenté mais, aujourd'hui, si un novice veut envoyer 30Mo de données à quelqu'un, il ne s'en sort pas (j'en ai vu plus d'un). Les méthodes existantes ne peuvent pas abstraire les concepts de clients serveur, IP, port, etc... C'est ce que Transfert essaie de faire! En fait plutôt que de nous battre sur la légitimité de notre protocole, discutons d'un remplaçant à celui ci. Nous avons besoin d'un protocole léger, qui permette de transférer des fichiers à la demande (sans partager), d'identifier ses utilisateurs ainsi que des relations entre eux et de chatter (même si on peux utilier un autre protocole comme Jabber pour ca). Et le top, il faudrai que le serveur centralisé (si besoin) tourne sur un serveur LAMP (gratuit chez tuxfamily). Connais tu un tel protocole?
La création de compte sert a gérer la liste des contacts et à s'identifier auprès des autres utilisateurs, le fait d'afficher une adresse IP en rebuterai surement plus d'un.
En fait le serveur sert à faire la correspondance entre identifiant et IP + Port, et à gérer la liste des contacts, rien d'autre!
[^] # Re: GPL != OpenSource != gratuit
Posté par yciabaud . En réponse à la dépêche Transfert: Echange de fichiers rapide et multiplateformes. Évalué à 3.
Le "donc" était de trop, "Open Source" et "gratuit " sont des caractéristiques differentes. J'en profite pour citer la licence...
[^] # Re: Mon avis
Posté par yciabaud . En réponse à la dépêche Transfert: Echange de fichiers rapide et multiplateformes. Évalué à 3.
Je suis tout à fait d'accord sur le besoin de convergence dans ce genre d'applis mais nous n'avons pas trouvé de protocole standardisé qui nous corresponde, on peut rêver que les prochaines applis utiliserons celui la!
[^] # Re: Mon avis
Posté par yciabaud . En réponse à la dépêche Transfert: Echange de fichiers rapide et multiplateformes. Évalué à 2.
Pour répondre, oui c'est encore une appli à laisser tourner sur le poste mais ponctuellement ça peut être très utile, notamment pour les néophytes, pour envoyer de gros fichiers persos en direct simplement et à des taux de transfert corrects.
Si l'appli vous plaît utilisez la et faite lui de la pub, on manque cruellement d'utilisateurs (même si cette annonce nous à fait progressé de 40% en 1 jours!!!)
Si vous avez des suggestions ou des questions je serai ravi de répondre.
Pour info, je suis l'un des 2 développeur de ce projet, on est étudiant en informatique en stage de fin d'études... (Je suis donc partial il faut le savoir)