MULTIPOINT BINARY FILE
TRANSFER
PROTOCOL (MBFT)
Recomendação T.127
Uma transferência de arquivo pela aplicação do usuário confia nos serviços de uma Entidade de Protocolo de Aplicação para Transferência de Arquivo (File Transfer Application Protocol Entity -File APE) que se comunica com pontos de aplicações de outros nodos. A File APE tem dois componentes, como mostrado na Figura 5: File Transfer Application Resource Manager (File ARM) e um File Transfer Application Service Element (File ASE). O ARM provê funcionalidade genérica, comum a todos os protocolos de aplicação, além disso, o ASE provê funcionalidade específica para este protocolo de aplicação habilitar interconexão de aplicações para transferência de arquivo. Note que este é um modelo conceitual e não se impõe nenhuma restrição na estrutura de implementações propostas.
Cada componente e serviço é descrito em mais detalhe abaixo:
| Página Inicial | Escopo e Definições | Introdução | Visão Geral | Aplicação | Abreviaturas |
Esta é a parte da aplicação de transferência de arquivo que envia aspectos que não têm nenhum efeito direto na interconexão (por exemplo, interface de usuário), podendo ser implementada em qualquer plataforma. Por ser executada na máquina cliente, a recomendação T-127 não cria restrições para a implementação. Uma aplicação de usuário confia nos serviços de uma APE se comunicar com pontos de aplicações em outros nodos. Não há comunicação com MCS ou GCC; isto é feito pelo File APE. A aplicação de usuário inicia uma sessão de transferência de arquivo por seu File APE e especifica as capacidades de aplicação e modo de sessão. Uma vez estabelecida a sessão, todo as transações específicas do MBFT são executadas pelo File APE em nome da aplicação de usuário.
O Gerente de Recursos de Aplicação para Transferência de Arquivo (File ARM) é responsável pela administração do GCC e recursos de MCS em nome do File ASE. Provê os seguinte serviços:
•
Responde a indicações de
GCC (por exemplo. permissão para registro,
invocação).
•
Associa o File APE com GCC.
•
Prende um domínio de MCS
para obter um Usuário de MCS ID para o File APE.
•
Une canais estáticos.
•
Identifica e une canais multicast usando
o Registro de GCC e MCS.
•
Reúne canais privados, admitindo
pontos File APEs nos canais.
•
Une qualquer canal privado para o qual o File APE foi admitido.
•
Identifica e obtém tokens
do Registro de GCC.
•
Apaga entradas do registro associadas com qualquer canal que pode ter
criado.
•
Invoca pontos File APEs a outros nodos.
• Processa a Lista de Aplicação informando sobre determinada lista de Capacidade de Aplicação que foi negociada e identifica o File APEs.
O Elemento de Serviço de Aplicação de Transferência de Arquivo (File ASE) proporciona funcionalidade de transferência de arquivo para a aplicação de usuário com recursos obtidos pelo File ARM. Sua operação é independente do tipo (estático ou dinâmico), identidade de tokens e canais utilizados. A aplicação de usuário especifica se o canal de broadcast ou acknowledged de dados é requerido. Para transferências privadas para um subconjunto da conferência, uma lista e MBFT User IDs também é requerido.
FIGURA
5 -Modelo de Aplicação - T.127
O File ASE provê os seguintes serviços:
•
Envia e recebe MBFT PDUs.
•
Obtém e libera tokens e determina
o estado do token que usando MCS.
•
Responde e libera às indicações do GCC-Conductor-Assign.
•
Emite pedidos ao GCC-Conductor-Permission-Ask
pelo Controlador de Nodo.
•
Responde às indicações do GCC-Conductor-Permission-Grant.
Uma sessão de MBFT usa canais de controle (control channels) para administração de transferências de arquivo e canal de dados (data channels) para distribuição de arquivo. Cada canal de controle tem um ou mais canais de dados associados; cada canal de dados suporta uma transferência de arquivo de cada vez.
Toda sessão de MBFT tem um canal de controle de sessão (chamada pelo mnemônico MBFT-CONTROL) e um canal de dados de broadcast (chamado pelo mnemônico MBFT-DATA) que deve ser reunido por todas as aplicações que participam daquela sessão. O canal de controle é usado para administrar todas as transferências de arquivo no canal de dados de broadcast. Todos os nodos são obrigados a receber os arquivos transmitidos no canal de dados de broadcast e descartados se o dados não forem requeridos. Isto pode levar a uma degradação desnecessária no desempenho da conferência se qualquer nodo que não requisitar os dados estiver usando links com baixa banda passante.
Uso de canais de dados acknowledged [chamado pelo mnemônico MBFT-DATA(n), onde n é o MCS Channel ID do canal de dados] permite a distribuição simultânea de mais de um arquivo. A gerência de transferências de arquivos nestes canais é feita pelo canal de controle de sessão, mas neste caso nodos têm a opção de rejeitar arquivos oferecidos a eles. Isto assegura que só são distribuídos arquivos a esses nodos que os requisitem, mas às custas de introduzir alguma perda de latência para cada transferência de arquivo.
Distribuição seletiva de arquivos para um subgrupo de participantes dentro de uma sessão existente pode ser obtida abrindo uma sub-sessão. Isto consiste em um canal de controle de sub-sessão privado [chamado pelo mnemônico MBFT-CONTROL(p), onde p é o MCS Channel ID do canal de controle]. Isto é usado para gerenciar transações de arquivo em zero ou um canal privado de dados de broadcast [chamado de MBFT-DATA(p), onde p é o MCS Channel ID do canal de dados] e zero ou mais canal privado de dados acknowledged [chamado de MBFT-DATA(n), onde n é o MCS Channel ID do canal de dados]. Um canal de controle privado separado é requerido para cada sub-sessão privada.
Cada canal de controle pode ter um token de FILE-REQUEST que é usado para assegurar que há um pedido de arquivo pendente no canal a qualquer instância. Um File ASE que requer um arquivo tem que obter o token antes de emitir o pedido e tem que bloquear o token até que outro nodo possa fornecer o arquivo. São permitidos canais de controle dinâmicos sem token de FILE-REQUEST mas só o criador de um canal pode emitir pedidos de arquivo naquele canal. O token para a sessão do canal de controle MBFT-CONTROL é nomeada pelo mnemônico FILE-REQUEST; o token para um canal de controle de sub-sessão MBFT-CONTROL(p) é File-REQUEST(p).
Cada canal de dados pode ter um token FILE-TRANSMIT que é usado para assegurar que há só uma transferência de arquivo em curso naquele canal de dados a qualquer instância. Um Arquivo transmitindo ASE agarra o token antes de oferecer um arquivo para transmissão e o bloqueia durante a transferência do arquivo, liberando o token depois do despacho do último bloco de dados do arquivo. Canal de dados dinâmicos sem um token FILE-TRANSMIT é permitido mas só o criador de tal canal pode enviar arquivos naquele canal. O token para a sessão de canal de dados de broadcast MBFT-DATA é chamado pelo mnemônico FILE-TRANSMIT, o token para uma sub-sessão de canal de dados de broadcast MBFT-DATA(p) é FILE-TRANSMIT(p), sendo que o token para canal de dados acknowledged MBFT-DATA(n) é FILE-TRANSMIT(n).
Juntos, estes canais e tokens incluem os recursos disponíveis para uma sessão de MBFT; eles podem ser estáticos ou dinâmicos. É a responsabilidade do Gerente de Recursos de Aplicação de Transferência de Arquivo (File ARM) determinar a identidade destes recursos. Para qualquer determinada transação de arquivo, a aplicação de usuário tem que especificar os recursos a ser usados pelo File ASE. Recursos estáticos e dinâmicos são tratados de forma idêntica pelo File ASE.
Capacidades de negociação para aplicações na transferência de arquivo é feito pelo mecanismo de registro (matrícula) da aplicação. Quando o File ARM emite um pedido GCC-Application-Enroll com a flag de Ativo/Inativo fixada para Ativo, indicará as capacidades de sua aplicação de usuário como parâmetro na Lista de Capacidades da Aplicação do pedido.
Um File APE é notificado das capacidades disponível dentro de sua sessão pelo recibo de uma indicação de GCC-Application-Roster-Report que contém a Lista de Aplicação para aquela sessão. A Lista de Aplicação inclui uma lista de nodos para qual um ponto File APE se registrou. Para cada nodo, a lista contém o GCC User ID daquele nodo e o MCS User ID(s) do ponto File APE(s) àquele nodo. A Lista de Aplicação tem um número de instância e contém flags para indicar se File APEs se juntou ou deixou a sessão desde que o prévio Application-Roster-Report foi emitido. Também contém uma flag que indica se a Lista de Capacidades de Aplicação foi atualizada desde a última lista e, nesse caso, a nova Lista de Capacidade. Se um File APE se registrou recentemente, a Lista de Capacidades de Aplicações é atualizada, com isto o File APE não tem acesso a instâncias prévias da lista.
A Lista de Capacidades de Aplicação recebida na indicação de GCC- Application-Roster-Report corresponde às quedas de Listas de Capacidades de Aplicação de todos os pontos File APEs registrados, i.e. inclui uma entrada para cada capacidade que foi declarada por qualquer ponto File APE. Para cada entrada inclui a ID de Capacidade, o número do ponto File APEs (inclusive o local) que tinha anunciado esta capacidade e, para capacidades na classe Unsigned Minimum, o valor mínimo do parâmetro entre todos os pontos File APEs que declararam esta capacidade.
A qualquer momento enquanto um File APE foi matriculado em uma conferência, pode receber indicação de GCC-Application-Roster-Report adicional e pode notificar isto de uma mudança nos conteúdos da lista. Isto pode acontecer devido a um novo ponto File APEs que se registra na conferência, pontos File APEs que deixam a conferência, ou pontos File APEs que tenham modificado a informação de matrícula delas.
Um File APE pode mudar sua Lista de Capacidades de Aplicação a qualquer hora por uma re-matricula. Feito isto, os File ARM emitem um GCC-Application-Enroll com a flag de Enroll/Unenroll fixando em Enroll (para registrar), inclusive uma revisão da Lista de Capacidades de Aplicação, e fornecendo todos os outros parâmetros como o valor inicial da matrícula ativa. Isto pode resultar em uma mudança na queda da capacidade fixada, em qualquer caso, todos os File APEs na sessão receberão uma indicação de GCC-Application-Roster-Report.
Qualquer mudança na configuração de capacidade de uma sessão de MBFT já não afetará as transações em curso. Mudanças deverão afetar as próximas transações a serem iniciadas.
Dois mecanismos estão disponíveis para suporte a transmissão simultânea de mais de um arquivo em uma conferência:
1)
Criação de uma sessão de MBFT adicional usando os procedimentos
definidos anteriormente.
2)
Criação de canais de dados acknowledged
dentro da sessão de MBFT existente.
Para modos estático e de multicast, multicast ou canais privados podem ser usados; para modo privado, deverão ser usados apenas canais privados. Deverá ser dada atenção particular no uso de canais de multicast, pois tais canais deixam de existir quando todos os usuários juntos se licenciam. Assim, é recomendado que File APEs só tentem usar um canal de multicast se eles não deixarem o canal desde que foi criado ou desde a última transação executada no canal.
Cada canal de dados acknowledged MBFT-DATA(n) requer seu próprio token FILE-TRANSMIT(n) para administrar transações de arquivo no canal, a menos que o uso seja restringido ao criador do canal.
Dois mecanismos estão disponíveis para permitir distribuição seletiva de arquivos a um subgrupo de participantes:
1)
Citar uma nova sessão
privada.
2)
Estabelecer uma
sub-sessão privada dentro da sessão MBFT existente.
Uma vez o caminho de comunicação foi estabelecido, o mecanismo usado para troca de arquivo é idêntico ao usado para o caminho de comunicação inicial.
Se uma aplicação deseja deixar uma sessão de MBFT, seu File ARM emitirá um pedido GCC-Application-Enroll com a flag de Enroll/Unenroll fixada em Unenroll. Nenhum outro parâmetro é requerido.
Se, a qualquer momento, o File ARM recebe uma indicação de GCC-Application-Roster-Report na qual já não é incluído (i.e. seu MBFT User ID está ausente), o File ARM emitirá um pedido de MCS-Detach-User imediatamente para separar da conferência especificada. A aplicação já não será considerada como participante da conferência corrente, mas pode tentar se matricular novamente na conferência emitindo um pedido GCC-Application-Enroll.
Se, a qualquer momento, o File ARM recebe uma indicação GCC-Application-Permission-To-Enroll com a flag de Grant/Revoke fixada para Revoke, é emito um pedido de MCS- Detach-User imediatamente para se retirar da conferência especificada. Já não será considerada como participante, a aplicação, na conferência e não tentará se registrar novamente.
Esta é uma característica opcional que permite a um File ASE obter a lista de um diretório que se encontra em um local remoto. Pode ser usado junto com o mecanismo de pedido de arquivo para prover um serviço de recuperação de arquivo. Um File ASE que requer a lista de diretório emite um Directory-RequestPDU para o Canal de Usuário MBFT do local remoto escolhido, usando os parâmetros especificados (RequestHandle e Reason).
Um File ASE que recebe um Directoy-RequestPDU tem que responder emitindo um Directory-ResponsePDU para o Canal de Usuário MBFT da origem, usando os parâmetros Result, PathName e DirectoryList. Se o File ASE é capaz de satisfazer o pedido, inclui uma lista de arquivos e sub-diretórios contida no diretório identificado no Directory-RequestPDU. Se estiver impossibilitado, o File ASE deverá indicar a razão da recusa na resposta. Deverá ser notado que não há nenhuma exigência para a estrutura de diretório apresentada para locais remotos, pois deverá estar igual ao apresentado da forma local.
Se um Arquivo individual ASE está impossibilitado de receber um arquivo ou determina que o dados já não serão mais necessários, ou se desconectará do canal de dados ou continuará recebendo os dados que estão para chegar e descartá-los.
Em modo de administraçao, File ASEs podem conceder permissão ao condutor de MBFT para emitir File-AbortPDUs que pode ser usado para ordenar um File ASE para terminar uma transferência de arquivo. Depois de receber um File-abortPDU, o transmissor é obrigado fixar em abort a flag para TRUE na atual File-DataPDU e então cessar a transmissão e renunciar o token FILE-TRANSMIT.
Este mecanismo pode ser usado pelo condutor de MBFT para terminar qualquer transferência de arquivo em curso, entrando em modo administração.
O transmissor pode cessar a sua própria transmissão, simplesmente fixando para abort a flag em um File-DataPDU.
O File-AbortPDU inclui um código de motivo para informar ao transmissor por que o aborte pedido foi gerado. A transmissão a ser terminada pode ser selecionada através de canal, MBFT User ID ou mais o manipulador de arquivo de MBFT User ID. Se nenhum parâmetro é incluído, então as transmissões em todos os canais (estática, multicast ou privado) por qualquer File ASE deve cessar. Se só a entrada MBFT User ID está presente, então o File ASE identificado tem que cessar a transmissão em todos os canais. Se o MBFT User ID e o manipulador de arquivo estão presentes, então a transação de arquivo especificada tem que terminar.
É disponibilizado suporte para troca de mensagens de diagnósticos entre envio e recebimento de locais por meio do File-ErrorPDU. O PDU contém três parâmetros de erro: um tipo de erro (indicando erro permanente, erro passageiro ou mensagem informativa), um identificador de erro e uma mensagem de texto opcional. A ação a ser levada após a recepção de um File-ErrorPDU não é definida por este protocolo.
Este PDU permite transmitir qualquer informação não-padrão e permite a aplicações implementar operações não-padrão. Uso de operações não-padrão pode estar sujeito a negociação de capacidades de não-padrão associadas. MBFT-NonStandardPDUs pode ser enviado a qualquer hora, mas em modo de administração só pode ser enviado por File APEs que foram concedidos o Privilégio de Não-padrão.
| Página Inicial | Escopo e Definições | Introdução | Visão Geral | Aplicação | Abreviaturas |