C-toxcore: 클라이언트 기능 패킷 구현

확인. 나의 제안.

아시다시피(아마도) 한 피어가 다른 피어에게 보내는(또는 다른 피어로부터 받는) 첫 번째 패킷은 PACKET_ID_ONLINE입니다. 이 패킷은 1바이트 길이(패킷 ID 포함)입니다. 내 제안은 이 패킷에서 클라이언트의 기능을 보내는 것입니다. 게다가, Isotoxin은 이미 이것을 하고 있습니다. 불행히도 현재 코어는 크기가 1바이트가 아닌 경우 이 패키지를 무시합니다. 그렇기 때문에 Isotoxin은 이 패킷을 두 번 보냅니다. 즉, 호환성을 위한 1바이트 길이와 기능 정보가 있는 전체 길이입니다.

기능 형식은 어떻습니까? key:valuen 형식의 단순한 문자열입니다

현재 Isotoxin의 기능 문자열:
options.client_capabilities = "client:isotoxin/" SS(PLUGINVER) "\n"
"support_bbtags:b,s,u,i\n"
"support_viewsize:1\n"
"support_msg_chain:1\n"
"support_msg_cr_time:1\n"
"support_video_ex:1\n"
"support_folder_share:1\n";

그런 방식이 마음에 들지 않는다면 PR을 할 수 있습니다.
또는 솔루션을 제공하십시오. 그러나 클라이언트는 첫 번째 패킷에서 다른 클라이언트의 기능을 알아야 합니다. 그렇지 않으면 클라이언트가 기능 패킷을 지원하는지 또는 이 패킷이 아직 수신되지 않았는지 이해하기 어려울 것입니다.

좋은 생각입니다. 많은 기능을 사용할 때만 문제가 발생합니다. 패킷 크기가 제한될 수 있습니다. 이것은 아마도 더 많은 패킷을 보내어 우회할 수 있지만 약간의 생각이 필요합니다.

client_capabilities 는 일관성을 위해 옵션 1과 같은 구조체여야 합니다. 다음과 같은 것을 보고 싶습니다.

/**
 * We assume every bool to be false if not specified.
 **/
struct Tox_Client_Capabilities {
  /**
   * The client name, lower case alphanumeric, no spaces. Dash allowed.
   */
  const char *client_name;

  /**
   * The client version, using Semantic Versioning. ie. `0.1.7`, `3.8.0-beta`, etc.
   */
  const char *client_version;

  /**
   * True if the client supports ToxMe/ToxDNS/QNL lookups.
   */
  bool supports_lookup;

  /**
   * True if the client supports ToxID sharing.
   * <strong i="7">@see</strong> Antox and Toxygen
   */
  bool supports_id_sharing;

  /**
   * True if the client supports ToxIdenticons.
   * <strong i="8">@see</strong> Ricin
   */
  bool supports_tox_identicons;

  /**
   * True if the client supports BBCode rendering.
   */
  bool supports_bbcode;

  /**
   * True if the client supports Markdown rendering.
   */
  bool supports_markdown;

  /**
   * True if the client supports audio calls.
   */
  bool supports_audio;

  /**
   * True if the client supports video calls.
   */
  bool supports_video;

  /**
   * True if the client supports file transfers.
   */
  bool supports_files;

  /**
   * True if the client supports inline images transfers.
   */
  bool supports_inline_images;

  /**
   * True if the client supports avatars.
   */
  bool supports_avatars;

  /**
   * True if the client supports message splitting.
   */
  bool supports_messages_split;

  /**
   * True if the client supports whateveryouwantoaddtothatlist.
   */
  bool supports_whatever;
}

client_capabilities는 구조체여야 합니다.

나쁜 생각. 내가 새로운 고유 기능을 생각해 낸다면? 이 구조를 확장하려면 먼저 코어에 PR을 해야 합니까? 아니요! 점차적으로 표준화된 문자열 집합만. 그렇지 않으면 작동하지 않습니다.

따라서 표준 형식을 사용하십시오. JSON, Yaml, TOML, 원하는 모든 것이지만 표준입니다. :)

나는 형식이 구현 세부 사항인 것을 선호합니다. toxcore가 이를 구문 분석하고 키/값과 유사한 API(예: all_capability_keys , value_for_key )를 제공할 수 있다면 좋을 것입니다.

@dvor toxcore가 키와 값을 구문 분석할 필요가 없어야 한다는 데 동의합니다. 이렇게 하면 클라이언트가 자신의 것을 구현할 수 있습니다.

이런 종류의 패킷에 대한 나의 제안:

[Fixed length binary Header] ... for client capability messages longer than one packet
key=value\n
...

헤더는 세그먼트 수를 uint16으로, 세그먼트 번호를 uint16으로 합니다.

키에 허용되는 문자는 [a-zA-Z0-9_] 입니다. 값에 허용되는 문자는 \n 및 = 제외한 모든 문자입니다. 바이너리 데이터는 base64로 인코딩됩니다.

현재 코어는 1바이트 길이의 PACKET_ID_ONLINE만 허용합니다.
내 제안은 이 사실을 기능 시퀀스의 끝으로 사용하는 것입니다.
이전 코어는 1바이트 PACKET_ID_ONLINE을 보내고 새 코어는 이를 시퀀스의 끝으로 해석하므로 기능 정보가 수신되지 않습니다.
새 코어는 마지막 1바이트 길이의 PACKET_ID_ONLINE 기능이 있는 PACKET_ID_ONLINE 수를 보냅니다. 이전 코어는 1바이트 PACKET_ID_ONLINE만 허용하며 정상적으로 작동합니다. 새로운 코어는 모든 >1바이트 PACKET_ID_ONLINE을 연결하고 클라이언트에 완전한 기능 정보를 제공합니다.

장점:

• 이전 코어와 새 코어 간의 완벽한 호환성
• 클라이언트는 tox_callback_friend_connection_status에서 기능 정보에 액세스할 수 있습니다.
• Isotoxin은 이미 이 방식을 사용하고 있습니다(연결 제외).

단점:

• ?