MULTIPOINT BINARY FILE
TRANSFER
PROTOCOL (MBFT)
Recomendação T.127
T.127 usa uma arquitetura de canais para controle e dados, para facilitar a transferência simultânea de um ou mais arquivos binários. Permite dar broadcast de arquivos a todos os participantes dentro de uma conferência, ou direcionar arquivos seletivamente para um subconjunto de locais em uma transferência de arquivo privada. Nenhuma restrição é feita aos tipos de dados que são transmitidos.
Dois tipos de canais são usados dentro de T.127: de controle e de dados. Canais de controle são usados para administrar todos os aspectos da transferência de arquivo (ofertas de arquivos, pedidos de arquivos), considerando que canais de dados são exclusivamente usados para a transferência de dados de arquivo. Só um arquivo pode ser transmitido em cada canal de dados de cada vez, mas podem ser usados canais de dados adicionais para permitir distribuição de arquivos múltiplos simultaneamente. O número de canais de dados em uso, em um determinado momento, depende do número de arquivos que estão simultaneamente sendo transmitidos.
Quando um grupo de aplicações de transferência de arquivos, que se comunicam entre si e trocam dados, dizemos que estão participando de uma sessão de transferência de arquivo. Cada sessão de transferência de arquivo requer um único canal de controle e um ou mais canal de dados para distribuição de arquivos a todas as aplicações que estão participando.
T.127 dá suporte a dois tipos de canal de dados: broadcast e acknowledged. Se um transmissor deseja enviar a todos os nodos um arquivo que está oferecendo, então deverá usar o canal de dados de broadcast. Todos os nodos têm que ficar ligados ao canal broadcast de dados durante a sessão de transferência do arquivo e é obrigatório receber todos os arquivos distribuídos neste canal; se um arquivo não é requerido, os receptores deverão descartá-lo. Se um transmissor deseja dar para outros nodos a opção de rejeitar um arquivo, deverá oferecer o arquivo em um canal de dados acknowledged. Neste caso, cada nodo tem que informar ao transmissor se deseja ou não os dados, e só esses que desejam o arquivo é que se ligam ao canal de dados. Transferências de múltiplos arquivos simultaneamente são suportados pelos canais de dados acknowledgeds.
Deverão ser usados canais de dados acknowledgeds se um transmissor considera os parâmetros do header de arquivo essenciais à operação da aplicação. Por exemplo, uma aplicação pode exigir preservar um pathname por receptores para referência futura. São identificados parâmetros chaves quando são oferecidos arquivos para distribuição; nodos que estão impossibilitados de suportar todos os parâmetros têm que rejeitar o arquivo.
O criador de um canal de dados acknowledged pode designá-lo para uso exclusivo (i.e. só o criador pode enviar arquivos no canal) ou compartilhado (i.e. qualquer participante pode enviar arquivos nele).
Transações com arquivos no canal de broadcast não requerem nenhum handshaking (estabelecimento de acordo) entre transmissor e receptores como nodos obrigados a receberem todos os arquivos distribuídos neste canal. Isto minimiza a latencia no começo de transferências de arquivo para transações no canal de dados de broadcast. Transações no canal de dados acknowledged provoca alguma latência no começo de uma transferência de arquivo, mas pode ter um desempenho global melhor evitando distribuição desnecessária de dados para locais que não estão desejando recebe-lo, particularmente em locais com largura de banda baixa. A escolha de canal está na discrição do transmissor e pode depender da aplicação, tamanho do arquivo, configuração da rede e número de participantes da conferência. Veja Figura 2.
Figura 2 - Modelo de Conferência no T-127
Obs:
1 - Todos os nodos estão ligados ao canal de controle e ao canal de broadcast de dados.
2 - Nodos devem podem receber arquivos no canal de broadcast de dados, requisitando-os ou não.
3 - Nodos só se ligam ao canal de dados acknowledged se estes desejarem receber os arquivos ofertados neste canal.
Distribuição seletiva de arquivos para um subconjunto de nodos dentro de uma conferência pode ser alcançada criando uma sessão privada de transferência de arquivo, ou estabelecendo uma sub-sessão privada de transferência de arquivo dentro da sessão existente.
Uma sub-sessão segue o mesmo modelo como uma sessão tendo um único canal de controle e um ou mais canais de dados. Veja Figura 3. Porém, difere de uma sessão, não é necessário ter um canal de dados de broadcast. Uma sub-sessão tem a mesma capacidade fixada de sua sessão pai e seus participantes são selecionados dos participantes da sessão pai. Sub-sessões não têm nenhum estado dentro do GCC e não aparecem no GCC-Application-Roster. Uma sub-sessão não tem uma definição de Sessão-ID, mas ao invés disso opera com a Sessão-ID da sessão do MBFT principal. Sub-sessões permitem iniciar trocas privadas de arquivo interativo de uma maneira expediente evitando a demora incorrida pelo processo de matrícula, e conservam GCC e recursos de MCS ao mesmo tempo.
Provisão é constituída por locais que solicitam um arquivo de outros nodos, permitindo a recuperação de informação de bancos de dados, boletins, etc. Deve ser fornecida informação suficiente no pedido para permitir de forma única ao local fonte a identificação do arquivo requerido.
Figura 3 - Relacionamento entre sessão e sub-sessão
Uma Sessão de MBFT é caracterizada pelos atributos seguintes como ilustrado na Figura 4.
• Um único canal de controle.
• Um único canal de dados de broadcast.
• Zero ou mais canais de dados acknowledgeds.
• Zero ou mais sub-sessões privadas (permite troca de arquivo entre um subconjunto selecionado de participantes da conferência).
• Uma Sessão ID.
Cada sub-sessão tem os seguintes atributos.
• Um único canal de controle privado.
• Zero ou mais canais de dados de broadcast privados.
• Zero ou mais canais de dados acknowledgeds privados.
• Nenhuma Sessão ID individual (opera com a Sessão ID da sessão de MBFT principal).
Figura 4 -Modelo de Canal
Cada canal de controle tem um token de FILE-REQUEST associado (a menos que o criador de canal requisite um direito exclusivo para solicitar arquivos de outros locais).
Cada canal de dados tem um token FILE-TRANSMIT associado (a menos que o criador de canal requisite um direito exclusivo para transmitir arquivos naquele canal).
Compressão pode ser aplicada a arquivos, sujeito a negociação com sucesso; por default arquivos estão sem compressão. Contudo, técnicas proprietárias de compressão podem ser utilizadas usando os formatos especificados na Recomendação T.124, por exemplo.
Na recomendação T.127 podemos ter tarefas background para transferência de dados de grande volume, assim como tarefas em foreground para distribuição imediata de arquivos. O modo a ser usado é selecionado no local de transmissão; deverá ser usada média prioridade para transferência rápida e baixa prioridade para transferência de dados de grande tamanho. A prioridade tem que permanecer a mesma ao longo da transmissão de um arquivo mas pode diferir entre sucessivas transações.
A administração de transações de arquivos no canal de controle usará alta prioridade.
Para minimizar tráfico na transferência de arquivos durante uma conferência interativa, arquivos podem ser antecipadamente transmitidos a uma conferência especificada. Este processo deve ser automatizado e os locais receptores podem identificar esses arquivos, mantendo o tráfico de arquivos na menor quantidade possível.