Conexão direta avançada - Advanced Direct Connect
| Conexão direta avançada | |
|---|---|
| Versão do protocolo: 1.0.3 | |
| Extensão Versão 1.0.8 | |
| http://www.adc.sourceforge.net | |
| Protocolo | |
| Extensões | |
Advanced Direct Connect ( ADC ) é um protocolo de compartilhamento e bate-papo ponto a ponto , usando a mesma topologia de rede , conceitos e terminologia do protocolo Direct Connect (DC).
"ADC" não oficialmente um acrônimo para "Advanced Direct Connect".
História
O ADC foi criado para permitir um protocolo extensível e resolver algumas deficiências do protocolo Direct Connect . Foi iniciado por Jacek Sieka , sob a influência do draft DCTNG de Jan Vidar Krey . A primeira revisão do ADC veio em 2004 e a primeira versão oficial em 2007-12-01.
Design e recursos
O ADC é estruturado em torno de clientes que se conectam a um hub central, onde os clientes (usuários) podem conversar e baixar arquivos de outros clientes (usuários). O hub fornece roteamento entre clientes para bate-papo, pesquisas e solicitações de conexões. As transferências de arquivos reais são entre clientes.
O protocolo em si é dividido em duas partes: um protocolo básico que cada cliente e hub, respectivamente, devem seguir e extensões que são opcionais. Os protocolos permitem a sinalização de recursos de protocolo (como filtros bloom ), e as mensagens podem ser construídas para serem roteadas apenas para aqueles que oferecem suporte a esse recurso específico.
Cada hub tem suas próprias regras e são normalmente regidos por operadores de hub. Os hubs podem definir diferentes recursos para operadores de hub. Os próprios hubs não regulam a discussão e os arquivos, mas os operadores dos hubs. O hub regula a participação mínima e a quantidade máxima de hubs simultâneos; coisas que são enviadas pelo cliente, em vez do usuário.
Existem listas de hubs onde o nome, a descrição, o endereço e as regras de um hub são especificados. Com a lista de hubs, os usuários podem escolher hubs semelhantes de acordo com a preferência do usuário por tópicos de discussão e arquivos.
A parte ponto a ponto do protocolo é baseada em um conceito de "slots" (semelhante ao número de posições abertas para um trabalho). Esses slots denotam o número de pessoas que podem fazer download de um usuário a qualquer momento. Os slots são controlados pelo usuário do respectivo cliente.
O ADC exige que todo o texto seja enviado em UTF-8 , o que significa que os usuários com codificação de sistema diferente (digamos, russo e chinês) podem conversar com os respectivos caracteres nativos.
O protocolo oferece suporte nativo a IPv6 .
Existem dois modos em que um usuário pode estar: "ativo" ou "passivo". Os clientes no modo ativo podem fazer download de qualquer outra pessoa na rede. Os usuários do modo passivo só podem fazer download de usuários ativos. Os clientes passivos receberão os resultados da pesquisa por meio do hub, enquanto os clientes ativos receberão os resultados diretamente. Um buscador ativo receberá (no máximo) 10 resultados por usuário e um buscador passivo receberá (no máximo) 5 resultados por usuário. A passagem NAT existe como uma extensão de protocolo, que permite que usuários passivos se conectem a outros usuários passivos.
O protocolo básico não requer criptografia , mas existem extensões para fornecer criptografia com TLS .
Os arquivos nas conexões do cliente são identificados por seu hash , mais comumente o Tiger Tree Hash . O algoritmo de hash é negociado com o hub e usado em toda a sessão cliente-hub, bem como nas conexões cliente-cliente subsequentes.
Protocolo
O protocolo ADC é um protocolo baseado em texto, onde os comandos e suas informações são enviados em texto não criptografado, exceto durante a negociação de senha. O aspecto cliente-servidor (assim como cliente-cliente, onde se atua como um "servidor") do protocolo estipula que o cliente fale primeiro quando uma conexão for estabelecida. Por exemplo, quando um cliente se conecta a um soquete de hub, o cliente é o primeiro a falar com o hub.
O protocolo exige que todo o texto seja enviado como Unicode codificado em UTF-8 , normalizado na forma C.
Não há padrões de porta , para hubs ou clientes.
Os endereços de hub têm o seguinte formato: adc: //example.com: 411, onde 411 é a porta.
Durante a troca de informações do protocolo cliente-hub, o cliente oferece um conjunto de hashes que ele suporta. O hub selecionará um desses hashes e esse hash será usado em toda a sessão hub-cliente. Se o hub considerar que o cliente não oferece suporte a um conjunto de hash apropriado (arbitrário), será gerado um erro.
O esquema de identificação global é baseado no conjunto hash produzindo dois hashes finais, onde um deles depende da saída do outro. Durante a troca de informações hub-cliente, o cliente enviará esses hashes finais, codificados com base32, que o hub confirmará para corresponder. Um desses hashes codificados em base32 será enviado posteriormente para outros clientes na rede. O esquema de identificação global é esta última string. O cliente pode alterar seus hashes finais em uma base hub a hub.
Cada usuário, durante uma sessão de hub, recebe um hash que dura apenas aquela sessão específica. Esse hash será usado para todas as referências de cliente nesse hub. Não há dependência de nicks.
Cada notificação de informação do cliente é enviada de forma incremental.
Uma solicitação de entrada para uma conexão cliente-cliente é vinculada a uma conexão real, com o uso de um token.
As pesquisas também usam um token para identificar cada resultado de uma pesquisa.
Não existe uma capacidade pronta para o uso de um cliente para chutar ou redirecionar outro cliente de um hub. O hub, no entanto, pode chutar e redirecionar arbitrariamente. O hub também pode exigir que todos os outros clientes no hub devem encerrar suas transferências com o cliente kickado / redirecionado. Se um cliente for redirecionado para outro hub, o cliente de redirecionamento deve usar um referenciador, semelhante ao referenciador HTTP . O cliente chutado / redirecionado não precisa receber uma mensagem de notificação.
A parte ponto a ponto do protocolo é baseada em um conceito de "slots" (semelhante ao número de posições abertas para um trabalho). Esses slots denotam o número de pessoas que podem fazer download de um usuário a qualquer momento. Esses slots são controlados pelo cliente. A alocação automática de slots é suportada pelo protocolo.
O token na conexão cliente-cliente decide quem deve ter permissão para fazer o download primeiro.
Os downloads são transportados usando TCP. As pesquisas podem ser transportadas usando TCP ou UDP.
Um cliente ativo possui uma porta de escuta para TCP e outra para UDP, embora as portas não dependam uma da outra.
Os delimitadores de protocolo são '\ n' e '' (espaço). O caractere '\' é usado como uma sequência de escape. As sequências de escape permitidas são "\ n" (nova linha), "\ s" (espaço) e "\\" (barra invertida).
O protocolo permite extensões como compactação com bzip2 ou criptografia com TLS . Embora o protocolo não exija que essas extensões sejam implementadas, os hubs podem exigi-las.
Veja também
Referências
- ^ Fredrik Ullner (março de 2007). "ADC: The run down" . DC ++: Apenas esses caras, você sabe? blog . Página visitada em 2013-12-13 .
- ^ Jan Vidar Krey (agosto de 2006). "ADC: Simplicidade de protocolo" . Jan Vidar Krey. Arquivado do original em 30/01/2013 . Página visitada em 2006-09-23 .
- ^ Fredrik Ullner (março de 2006). "Poder + Pessoa = Operador" . DC ++: Apenas esses caras, você sabe? blog . Página visitada em 2013-12-13 .
- ^ Fredrik Ullner (janeiro de 2007). "As partes de uma lista de hubs" . DC ++: Apenas esses caras, você sabe? blog . Página visitada em 2013-12-13 .
- ^ Fredrik Ullner (março de 2006). "Slots, slots, slots ..." . DC ++: Apenas esses caras, você sabe? blog . Página visitada em 2013-12-13 .
- ^ Fredrik Ullner (dezembro de 2010). "Extensões ADC - NATT - NAT traversal" . Projeto ADC . Página visitada em 2013-12-13 .
- ^ Fredrik Ullner (dezembro de 2010). "Extensões ADC - ADCS - Criptografia Simétrica em ADC" . Projeto ADC . Página visitada em 2013-12-13 .
- ^ En_Dator (março de 2009). "TLS e criptografia" . ADCPortal. Arquivado do original em 07-07-2011 . Página visitada em 01-03-2009 .
