C-toxcore: 機能提案:ネットワークバウンサー

作成日 2018年01月18日  ·  11コメント  ·  ソース: TokTok/c-toxcore

このアイデアは、IRCバウンサーにほぼ似ており、ネットワークに接続されたままのプロキシ/リレークライアントをセットアップし、実際のクライアントは通信のためにバウンサーに接続/切断します。 これは、DHTによるバッテリーの消耗や電話会社のネットワークコストに悩まされているモバイルシステム(スマートフォンなど)の採用に特に役立ちます。

これについてのみ言及します。これは、主にモバイルユーザーであり、前述の欠点を容認できないと考えているという理由だけで、少なくとも3人がネットワークを放棄したためです。

P3 proposal

最も参考になるコメント

tox.hインターフェイスを公開するバウンサーライブラリを記述して、クライアントコードを変更することなく、クライアントをtoxcoreであるかのように構築できるようにする必要があります。 たとえば、このバウンサーライブラリのtox_bootstrap()関数に対してクライアントが最初に行う呼び出しは、バウンサーライブラリが接続する必要のあるバウンサーデーモンのaddress:port :pubkeyとして扱うことができます。 接続が確立されると、クライアント上のすべてのtox_関数はリモートバウンサーのRPCになります。たとえば、 tox_friend_send_message()を実行しているクライアントは、デーモンにRPCを送信して、そのマッサージを送信するように要求します。代わりに機能コードを返送して、クライアントに返します。 バウンサーライブラリは、プレーンHTTPS(ネットワークの使用量を減らしたい場合はおそらくこれが必要です)からtoxcoreのカスタムパケットまで、リモートサーバーで実行されているバウンサーデーモンとの通信に必要なものをすべて使用できます。

ええ、私は@ sudden6に同意します。これは、toxcoreライブラリの一部ではなく、別のライブラリである必要があります。

全てのコメント11件

この機能は、コアライブラリではなく、ボットに実装した方がよいと思います。

tox.hインターフェイスを公開するバウンサーライブラリを記述して、クライアントコードを変更することなく、クライアントをtoxcoreであるかのように構築できるようにする必要があります。 たとえば、このバウンサーライブラリのtox_bootstrap()関数に対してクライアントが最初に行う呼び出しは、バウンサーライブラリが接続する必要のあるバウンサーデーモンのaddress:port :pubkeyとして扱うことができます。 接続が確立されると、クライアント上のすべてのtox_関数はリモートバウンサーのRPCになります。たとえば、 tox_friend_send_message()を実行しているクライアントは、デーモンにRPCを送信して、そのマッサージを送信するように要求します。代わりに機能コードを返送して、クライアントに返します。 バウンサーライブラリは、プレーンHTTPS(ネットワークの使用量を減らしたい場合はおそらくこれが必要です)からtoxcoreのカスタムパケットまで、リモートサーバーで実行されているバウンサーデーモンとの通信に必要なものをすべて使用できます。

ええ、私は@ sudden6に同意します。これは、toxcoreライブラリの一部ではなく、別のライブラリである必要があります。

私はRPCライブラリについては考えていませんでしたが、メッセージを保存してテキストコマンドで転送するだけのボットのようなものでした。

ボットとどのように通信しますか? Toxボットの場合、zer0defが避けたいDHTに接続する必要はありませんか?

@ sudden6ボットではなくIRCバウンサーの観点から考えていました。 IRCバウンサーに精通しているかどうかわからないので、GUI + toxcoreであるqToxクライアントを想像してみてください。ただし、ローカルマシンでGUIとtoxcoreを実行する代わりに、マシンでGUIを実行し、toxcoreはGUIを実行します。と通信するのはリモートサーバーで実行されています。 これは、toxcoreのふりをするライブラリを作成することで実現できます。これにより、qToxはコードを変更せずにコンパイルできますが、実際にはtoxcoreではなく、リモートのtoxcoreインスタンスと通信するライブラリになります。

しかし、これはモバイルクライアントがTCPモードを介して利用するフルノードに実装されていませんか? 私の理解では、TCPモードはDHTネットワークに参加していません。

@dingosanは、TCPノードに常に接続している必要があります。 私が理解した限りでは、用心棒もメッセージを保存しますか?

@ sadden6おそらくログの一貫性を維持する必要があります。そうでない場合は、クライアントをTCPノードとして実行するだけで十分です。

こんにちは、私はtoxcoreプロトコルを変更せずにこのような作業を行っています。
IRCのような用心棒ではなく、橋のようなものです。
ネイティブプログラムクライアントとウェブアプリの両方をサポートするためにgRPC / websockを使用しています。
ブリッジは、オンラインのときにすべてのメッセージを保存します。 また、すべてのブリッジのクライアントは同期されたメッセージを受信できます。
クライアントはすべての履歴メッセージをプルでき、複数のクライアントはブリッジの原因を利用してメッセージを相互に同期できます。

これは進行中の作業ですが、まだデモです。興味のある人は誰でも見ることができます。
https://github.com/envsh/tox-homeserver

問題は、グループが一時的なものであり、グループを再作成した後にグループメッセージをマージする良い方法がないことです。

きちんとした:)素晴らしいですね!

問題は、グループが一時的なものであり、グループを再作成した後にグループメッセージをマージする良い方法がないことです。

qToxでも同じ問題があります。 永続的なグループは一意のIDを持っているため、これが可能になります。 別の方法は、作成された各グループを個別に扱い、それらすべてを個別の履歴としてユーザーに表示することです。 このような:

26.05.2018 12:45 Tox Public Chat
26.05.2018 11:31 #toktok
26.05.2018 10:15 meeting
25.05.2018 08:10 meeting
24.05.2018 01:20 Tox Public Chat

それはそれほど良くはありませんが、それでも使用可能です。 このように歴史を見たいと思う人もいるかもしれません。

このページは役に立ちましたか?
0 / 5 - 0 評価