BR102015020596A2 - mecanismo e método para comunicação - Google Patents

Abstract

resumo “mecanismo e método para comunicação” a presente invenção se refere a um mecanismo e método para acessar os dados da mensagem em uma memória compartilhada por pelo menos um cliente, inclui uma alocação de dados na memória compartilhada, a memória é configurada em uma pluralidade de buffers, e acessar os dados por um cliente ou um servidor sem bloquear ou restringir o acesso aos dados.

Description

“MECANISMO E MÉTODO PARA COMUNICAÇÃO” Antecedentes da invenção [001] Uma unidade substituível em linha (LRU) é um componente modular de uma unidade maior, como um veículo ou aeronave, e é planejada para especificações que garantam a possiblidade de ser intercambiada e/ou substituída em caso de falha. As LRUs de uma aeronave, por exemplo, podem incluir sistemas, sensores, rádios, ou outros equipamentos auxiliares inteiramente contidos para controlar e/ou operar funções da aeronave. No ambiente da aeronave, as LRUs podem ser projetadas para operar de acordo com uma operação, interoperabilidade, e/ou padrões do fator tamanho específicos, como os definidos pelos padrões da série ARINC. [002] Uma pluralidade de LRUs pode ser interconectada por uma rede de dados para acessar ou trocar dados em uma memória comum ou compartilhada de um computador de controle de voo ou de outro sistema computadorizado. O computador de controle de voo ou de outro sistema computadorizado pode ainda controlar e/ou operar as funções da aeronave.

Breve Descrição da Invenção [003] Em uma modalidade, um mecanismo para comunicação entre pelo menos um cliente e pelo menos um servidor através do acesso aos dados da mensagem em uma memória compartilhada, inclui uma alocação dos dados na memória compartilhada em pelo menos um slot de correio, a alocação sendo acessível por um endereço constante predeterminado, e um conjunto de buffers para cada cliente entre o pelo menos um cliente, e em que cada buffer pode ser controlado tanto pelo respectivo cliente quanto pelo servidor, o pelo menos um slot de correio contendo referências que identificam o pelo menos um cliente e o pelo menos um servidor, o pelo menos um cliente tendo um ponteiro de acesso ativo que habilita o pelo menos um cliente a manipular diretamente os dados da mensagem por meio de um buffer controlado pelo cliente, o pelo menos um servidor tendo um ponteiro de acesso ativo que habilita o pelo menos um servidor a manipular diretamente os dados da mensagem por meio de um buffer controlado pelo servidor. Os ponteiros de acesso ativos são alocados entre buffers que usam apenas operações atômicas sem copiar os dados ao nível do sistema operacional. [004] Em outra modalidade, um método para comunicação entre pelo menos um cliente e um servidor através do acesso aos dados da mensagem em uma memória compartilhada, sendo que o método inclui alocar os dados na memória compartilhada em pelo menos um slot de correio, designar um único endereço predeterminado para acessar cada pelo menos um slot de correio, alocar diversos buffers para cada cliente entre o pelo menos um cliente, cada buffer sendo controlável pelo cliente ou sendo controlável pelo servidor, o número de buffers sendo igual ao número de transações solicitadas pelo respectivo cliente, e alocar um ponteiro de acesso ativo do cliente do um buffer controlado pelo cliente para alterar o controle do buffer controlado pelo cliente para um buffer controlado pelo servidor que habilita o servidor a manipular diretamente os dados da mensagem por meio de um ponteiro de acesso ativo do servidor. Os dados da mensagem são acessados por meio de ponteiros de acesso ativos aos buffers sem copiar os dados da mensagem ao nível do sistema operacional.

Breve Descrição dos Desenhos [005] Nos desenhos: A Figura 1 é uma vista esquemática de cima para baixo da aeronave e da rede de comunicações de acordo com uma modalidade da invenção. A Figura 2 é uma vista esquemática da comunicação entre uma pluralidade de clientes e/ou servidores acessando a memória compartilhada, de acordo com uma modalidade da invenção. A Figura 3 é uma vista esquemática dos clientes acessando os buffers de um slotóe correio, de acordo com uma modalidade da invenção. A Figura 4 é uma vista esquemática dos espaços de memória unidirecional e bidirecional, de acordo com uma modalidade da invenção. A Figura 5 é uma vista esquemática de um mecanismo para que os clientes acessem os dados da mensagem em um buffer, de acordo com uma modalidade da invenção. A Figura 6 é uma vista esquemática de um mecanismo para que os clientes realizem uma leitura/gravação da transação para os dados em um buffer, de acordo com uma modalidade da invenção. A Figura 7 é uma vista esquemática de um mecanismo para direcionar um cliente ao buffer seguro, de acordo com uma modalidade da invenção.

Descrição das Modalidades da Invenção [006] As modalidades descritas da presente invenção estão ilustradas no ambiente da aeronave dotada de uma rede de dados interconectando a memória comum ou compartilhada acessível a uma pluralidade de sensores, sistemas, e componentes da aeronave. No entanto, as modalidades da invenção podem ser estabelecidas em qualquer ambiente que utilize clientes e servidores com acesso à memória comum ou compartilhada. Ademais, muito embora “clientes” e “servidores” sejam descritos a seguir, será possível perceber que as modalidades particulares descritas são exemplos não limitantes de clientes e servidores. Exemplos adicionais de clientes e servidores podem incluir unidades discretas, aplicativos, processos computadorizados, threads de processamento, etc., remotos (via rede de dados ou Internet) ou localizados ou qualquer combinação dos citados, com acesso a uma memória compartilhada. Por exemplo, toda uma pluralidade de “clientes” pode residir em um único computador ou unidade computacional, acessando a memória de acesso aleatório comum (RAM). [007] Como ilustra a Figura 1, é mostrada uma aeronave 8 que tem uma fuselagem 10 e pelo menos um motor de turbina, mostrado como um sistema do motor esquerdo 12 e um sistema do motor direito 14. Os sistemas do motor direito e esquerdo 12, 14 podem ser substancialmente idênticos. Embora os motores da turbina 12, 14 estejam ilustrados, a aeronave pode incluir um número maior ou menor de sistemas de motor, ou sistemas alternativos do motor de propulsão, como motores de hélice. A aeronave 8 mostrada compreende adicionalmente uma pluralidade de sensores, sistemas, e componentes, coletivamente denominados unidades substituíveis em linha (LRUs) 18, e pelo menos um servidor 20 ou unidade computacional, mostrado como dois sistemas de gerenciamento de voo, ou computadores de controle de voo, com localizações próximas entre si, perto do nariz da aeronave 8. Pelo menos um dos servidores 20 pode incluir adicionalmente a memória 22. As LRUs 18 e os servidores 20 podem ser interconectados comunicativamente por linhas de transmissão e/ou comunicação que definem uma rede de comunicação de dados 24, que atravessa pelo menos uma porção da aeronave 8. Exemplos de LRUs 18 podem incluir sistemas de gerenciamento de voo e/ou sistemas de manutenção a bordo. LRUs adicionais 18 podem ser incluídas. Embora conste a descrição de um servidor 20, as modalidades da invenção podem incluir qualquer sistema computacional, computador de voo, ou sistema de exibição que exiba os dados provenientes de múltiplos sistemas. [008] A memória 22 pode incluir uma memória de acesso aleatório (RAM), memória flash, ou um ou mais tipos distintos de memória eletrônica portátil, etc., ou qualquer combinação adequada desses tipos de memória. As LRUs 18 e/ou servidores 20 podem ser acoplados operacionalmente à memória 22 de modo que as LRUs 18 e/ou os servidores 20, ou quaisquer programas ou processos de computador contidos naqueles, possam acessar pelo menos uma porção da memória 22 (por exemplo, a “memória compartilhada” 22). [009] Como aqui utilizado, “programas” e/ou “processos” podem incluir todos ou uma porção de um programa de computador contendo um grupo de instruções executável para controlar o gerenciamento e/ou a operação de pelo menos uma das funções da respectiva LRU 18, servidor 20, ou aeronave 8. O programa e/ou os processos podem incluir um produto de programa de computador apto a incluir meios legíveis por máquina para carregar ou conter instruções executáveis por máquina ou estruturas de dados armazenadas naqueles. Os meios legíveis por máquina podem ser qualquer meio disponível que possa ser acessado por um computador de uso geral ou específico ou por outra máquina contendo um processor. De modo geral, esse programa de computador pode incluir rotinas, programas, objetos, componentes, estruturas de dados, algoritmos, etc. que tenham o efeito técnico de executar tarefas particulares ou de implantar tipos particulares de dados abstratos. As instruções executáveis por máquina, estruturas de dados associadas, e programas representam exemplos de código de programa para executar a troca de informações conforme aqui revelado. As instruções executáveis por máquina podem incluir, por exemplo, instruções e dados, que fazem com que um computador de uso geral, computador de uso específico, controlador, ou máquina de processamento de uso específico realizem certa função ou grupo de funções. [010] A aeronave 8 mostrada na Figura 1 é meramente uma representação esquemática de uma modalidade da invenção, e é utilizada para ilustrar que uma pluralidade de LRUs 18 e servidores 20 pode estar localizada ao longo de toda a aeronave 8. A localizada exata das LRUs 18 e servidores 20 não são inerentes às modalidades da invenção. Adicionalmente, um número maior ou menor de LRUs 18 e/ou servidores 20 pode ser incluído nas modalidades da invenção. [011] A rede de comunicações 24 é ilustrada como um barramento, podendo incluir diversos conectores e interfaces de comunicação de dados, por exemplo, Ethernet ou cabos de fibra óptica, e componentes de roteamento e/ou comutação, para facilitar a interconexão comunicativa entre as LRUs e os Servidores 20. Ademais, a configuração e a operação da rede de comunicações 24 pode ser definida por um conjunto comum de padrões ou regulamentações aplicáveis a ambientes particulares da aeronave. Por exemplo, a rede de comunicações 24 em uma aeronave 8 pode estar definida por, e/ou configurada de acordo com o padrão ARINC 664 (A664), ou de acordo com o padrão ARINC 653 (A653), estando cada um deles incorporado a este documento por meio de citação em sua totalidade. [012] A Figura 2 mostra uma ilustração esquemática de um sistema de comunicação de dados 24 de acordo com uma modalidade da invenção. Uma pluralidade de LRUs 18, cada uma delas incluindo um ou mais threads ou processos computadorizados 26, tem acesso à memória compartilhada 22, mostrada como RAM compartilhada. Adicionalmente, um ou mais servidores 20, cada um deles incluindo um ou mais threads ou processos computadorizados 28, também tem acesso à memória compartilhada 22. Nesse sentido, cada processo 26, 28 pode ter acesso à memória compartilhada 22. [013] A memória 22 mostrada compreende adicionalmente uma alocação de dados 30 em pelo menos um agrupamento, ou “slot de correio” 32, posicionado em um local de memória endereçável constante predeterminado, ou “endereço constante” 34 da memória 22. Como aqui utilizado, um “slot de correio” pode incluir um subconjunto predeterminado da memória 22 alocado para um uso particular do armazenamento de dados para a aeronave 8. Por exemplo, um único slot de correio 32 pode compreender uma única alocação de dados, como a velocidade do ar da aeronave 8, enquanto outro slot do correio 32 pode compreender uma pluralidade de elementos de dados relacionados ou não relacionados, como pontos de notificação (waypoints) ou o plano de voo atual. As modalidades da invenção podem incluir configurações onde cada slot de correio 32 individual utiliza as mesmas definições de dados da mensagem, ou onde diferentes definições de dados da mensagem são utilizadas em diferentes slots de correio 32. Como mostrado, os slots de correio 32 podem ser organizados de maneira sequencial originando-se do endereço constante 34, como uma lista simplesmente ligada; no entanto, estruturas de organização adicionais dos slots de correio 32 podem ser configuradas para incluir matrizes, alocações variáveis para cada slot de correio 32, etc., todas se originando do local de endereço constante 34. [014] Cada um dos processos 26, 28, e/ou respectivamente, as LRUs 18 e os servidores 20 são configurados previamente para incluir o endereço constante predeterminado 34 da memória compartilhada 22. Nesse sentido, cada processo 26, 28, LRU 18, e/ou servidor 20 é configurado previamente para identificar a localização do endereço constante 34, e consequentemente, o um ou mais slots de correio 32 contendo os dados a serem acessados. Como aqui utilizado, cada LRU 18 e/ou cada processo da LRU 26 pode ser considerado um “cliente” para acessar os dados na memória compartilhada 22, e cada servidor 20 e/ou cada processo do servidor 28 pode ser considerado um “servidor” para acessar os dados na memória compartilhada 22. É possível incluir modalidades adicionais nas quais os servidores 20 realizam ações ou funções similares aos clientes, e os clientes realizam ações ou funções similares aos servidores 20. Nesse sentido, “clientes” e “servidores” podem realizar funções intercambiáveis, salvo indicação em contrário. Adicionalmente, embora o servidor 20 e as LRUs 18 sejam ilustrados como componentes separados, as modalidades da invenção podem incluir servidores 20 ou clientes que residam nos mesmos sistemas do outro, e/ou no mesmo sistema da memória compartilhada 22. [015] Em uma modalidade da invenção, o número de slots de correio 32 na memória compartilhada 22 é definido previamente durante a inicialização da memória 22, em função do número conhecido de slots de correio 32 acessível aos clientes e/ou servidores. Em outra modalidade da invenção, o número de slots de correio 32 é definido na ou durante o tempo de execução pelo número coletivo de slots de correio 32 acessível pelos clientes e/ou servidores. Nesse sentido, o número de slots de correio 32 pode ser dinâmico, crescente e decrescente, conforme a necessidade, ou somente aditivo quando os slots de correio adicionais 32 precisam ser acessados. [016] Em atenção agora à Figura 3, a memória compartilhada 22 pode estar em comunicação com diversos clientes 40 e servidores 50. Cada slot de correio 32 da memória compartilhada 22 pode compreender adicionalmente uma lista de referência 33 que inclui uma lista de referências para cada um ou mais clientes 40 e um ou mais servidores 50 que podem estar associados àquele slot de correio particular 32. A lista de referência 33 pode incluir, por exemplo, informações de roteamento, fonte, e/ou destino associado a cada um dos respectivos clientes 40 e/ou servidores 50, de modo que, por exemplo, um cliente 40 ou servidor 50 pode consultar a lista de referência 33 da memória compartilhada 22 para obter pelo menos um caminho de comunicação com o outro respectivo servidor 50 ou cliente 40. Nesse sentido, o uso do endereço constante 34 e slot de correio conhecido 32 contendo a lista de referência 33 facilita a comunicação entre um ou mais clientes 40 e/ou servidores 50 sem a necessidade de definir mecanismos de comunicação direta entre os clientes 40 e/ou servidores 50 entre si. [017] Como mostra a representação esquemática, cada um ou mais clientes 40, compreende ainda um ponteiro de acesso ativo 42 capaz de identificar um espaço da memória endereçável específico, ou pluralidade de agrupamentos do espaço da memória, como buffers, de modo que o cliente pode acessar o um ou mais buffers. Como mostrado, um primeiro cliente 54 pode acessar um primeiro espaço da memória endereçável 55 associado ao primeiro cliente 54, e que inclui diversos buffers 36. Como também é mostrado, um segundo cliente 56 pode acessar um segundo espaço da memória endereçável 57 associado ao segundo cliente 56 e que inclui um segundo número de buffers 36. Cada um dos respectivos espaços de memória endereçáveis 55, 57 são identificados e gerenciados por seus respectivos clientes 54, 56 e/ou por seus respectivos ponteiros de acesso ativos 42 do cliente. Cada buffer da pluralidade de buffers 36 pode ser configurado para armazenar um volume predeterminado de dados, conforme a necessidade, para um elemento de dados particular. As modalidades da invenção podem incluir configurações onde, por exemplo, o primeiro cliente 54 consegue acessar somente seu próprio espaço da memória 55 e/ou os buffers 36 associados a um slot de correio particular 32, portanto, não consegue acessar, por exemplo, o espaço da memória 57 do segundo cliente 56. Nesse sentido, cada cliente 54, 56 “possui” seus respectivos espaços de memória 55, 57, muito embora o controle individual dos buffers 36 possa ser designado a outros componentes. Embora os clientes 40 possam estar limitados a seus respectivos espaços de memória 55, 57, os servidores 50 podem acessar os buffers 36 nos espaços de memória 55, 57 de qualquer cliente 40. [018] O número de buffers 36 para cada espaço da memória endereçável 55, 57 pode ser definido pelo número de transações solicitadas por cada respectivo cliente 54, 56. Como opção, o número de buffers 36 para cada espaço da memória endereçável 55, 57 pode ser definido pelo número de transações solicitadas por cada respectivo cliente 54, 56, mais um buffer extra 36. Portanto, no exemplo ilustrado, o primeiro cliente 54 solicitou realizar duas transações na memória compartilhada 22, e recebeu três buffers 36 (dois mais um buffer extra), ao passo que o segundo cliente 56 solicitou realizar três transações na memória compartilhada 22, e recebeu quatro buffers 36 (três mais um buffer extra), [019] Em uma modalidade da invenção, o número de buffers 36 em cada espaço da memória endereçável 55, 57, e o tamanho de cada buffer 36 são definidos previamente durante a inicialização da memória compartilhada 22, em função do número conhecido de clientes 40 capaz de acessar o slotóe correio 32, e de um número conhecido de transações. Em outra modalidade da invenção, o número de buffers 36 em cada espaço da memória endereçável 55, 57 é definido no ou durante o tempo de execução pelo número coletivo de clientes 40, que então estejam acessando o slot de correio 32, e pelo número de transações que são solicitadas. Nesse sentido, o número de buffers 36 pode ser dinâmico, crescente e decrescente, conforme a necessidade, ou somente aditivo quando os clientes adicionais 40 estão acessando o slot de correio 32, ou transações são solicitadas. Em outras modalidades da invenção, o slot de correio 32 e o espaço da memória endereçável 55, 57 podem ser configurados de modo independente. Por exemplo, o slot de correio 32 pode ser definido previamente conforme esclarecido, mas o espaço da memória endereçável 55, 57 é configurado dinamicamente durante o tempo de execução, ou vice-versa. Em qualquer um dos exemplos, pré-definidos ou dinâmicos, o número de slots de correio 32 e/ou a configuração dos buffers 36 pode ser definido de acordo com um algoritmo ou programa executável armazenado na memória compartilhada 22. [020] Adicionalmente, cada um ou mais servidores 50, compreende um ponteiro de acesso ativo 52, e é capaz de acessar um buffer 36 específico indicado pelo respectivo ponteiro de acesso ativo 52. Por exemplo, um servidor 50 pode acessar a lista de referência 33 do slot de correio 32 que consegue identificar pelo menos um entre um cliente 40 e/ou um espaço da memória endereçável 55, 57 associado àquele cliente 40, e os buffers 36 ali contido. No exemplo ilustrado, o primeiro cliente 54 está associado a um primeiro buffer 58. As modalidades da invenção podem incluir apenas um único servidor 50 que se comunica com cada slot de correio 32. [021] A Figura 4 ilustra ainda uma vista esquemática alternativa da configuração e da operação de um espaço da memória endereçável 55, 57 do cliente. Um espaço da memória unidirecional 80 mostrado compreende pelo menos uma fila do buffer disponível 82 gerenciada por um cliente 40 (não mostrado) e uma fila do buffer de solicitação 84 gerenciada por um servidor 50 (não mostrado). A fila do buffer disponível 82 pode ser configurada para reter o número máximo de buffers 36 disponível no espaço da memória 80, enquanto a fila do buffer de solicitação 84 pode ser configurada para reter o número máximo de buffers 36 solicitados pelo cliente 40 (isto é, o número máximo de buffers 36 no espaço da memória 80, menos um). Nas modalidades em que nenhum buffer “extra” está incluído, a fila do buffer disponível 82 e a fila do buffer de solicitação 84 podem ser configuradas para reter o mesmo número de buffers, igual ao número máximo de buffers 36 solicitados pelo cliente 40. [022] No exemplo ilustrado, os buffers 36 podem incluir o conteúdo de dados, ou a mensagem que é intermediada pelo respectivo cliente 40 e/ou servidor 50. Como o cliente 40 faz solicitações de transações unidirecionais (que uma transação está aguardando a interação com o servidor 50; por exemplo, “solicitação pendente”), um buffer 36 para cada solicitação de transação pode transferir para a fila do buffer de solicitação 84 a fim de aguardar a transação ou o processamento por um servidor 50. Uma vez que o servidor 50 execute e/ou processe a transação solicitada, o buffer 36 é devolvido para a fila do buffer disponível 82 para que o cliente 40 realize outras solicitações de transação. O cliente 40 pode, em alternativa, realizar transações e/ou processamentos adicionais nos dados da mensagem do buffer 36 quando devolvido da fila do buffer de solicitação 84 antes de devolver o buffer 36 à fila do buffer disponível 82. Como aqui utilizado, os buffers 36 alocados na fila do buffer disponível 82 podem ser considerados “disponíveis” ou “desocupados” para iniciar novas transações, enquanto os buffers 36 alocados na fila do buffer de solicitação 84 podem ser considerados “indisponíveis” ou “ocupados”. [023] Ademais, como a fila do buffer de solicitação 84 pode estar configurada com um espaço da fila do buffer 36 menos disponível do que a fila do buffer disponível 82, as modalidades da invenção podem incluir configurações nas quais o cliente 40 não consegue realizar solicitações de transação concluídas copendentes {por exemplo, nem todos os buffers 36 podem estar simultaneamente na fila do buffer de solicitação 84) em todos os buffers disponíveis 36 de seu respectivo espaço da memória 80. Embora a ilustração mostre os buffers 36 se movendo de uma fila 82, 84, para outra fila 82, 84, percebe-se que o próprio buffer 36 não troca de local no espaço da memória 80. Nesse sentido, as filas 82, 84 podem ser “filas virtuais”. As filas 82, 84 podem ilustrar apenas uma modalidade da invenção demonstrando a posse dos respectivos buffers 36 durante o processamento da transação no espaço da memória unidirecional 80. [024] Um espaço da memória bidirecional 86 é ilustrado adicionalmente e pode compreender a fila do buffer disponível 82 e a fila do buffer de solicitação 84, conforme explicado acima, além da fila do buffer de resposta 88, gerenciada por um cliente 40 (não mostrado). A fila do buffer disponível 82 e a fila do buffer de solicitação 84 do espaço da memória bidirecional 86 opera de maneira similar às operações descritas acima, salvo indicação em contrário. Como mostrado, a fila do buffer de resposta 88 também pode ser configurada para reter o número máximo de buffers 36 solicitados pelo cliente 40 (isto é, o número máximo de buffers 36 no espaço da memória 80, menos um), Nas modalidades em que nenhum buffer “extra” é incluído, a fila do buffer solicitado 88 pode ser configurada para reter diversos buffers, equivalente ao número máximo de buffers 36 solicitados pelo cliente 40. [025] Uma diferença entre o espaço da memória unidirecional 80 e o espaço da memória bidirecional 86 consiste em: uma vez que o servidor 50 execute e/ou processe a transação solicitada na fila do buffer de solicitação 84, o buffer 36 é transferido para a fila do buffer de resposta 88 com vistas a algum processamento adicional pelo cliente 40 (a transação está aguardando a interação com o cliente 40; por exemplo, “resposta pendente”). Uma vez concluído o processamento adicional pelo cliente 40 na fila do buffer de resposta 88, o buffer 36 é devolvido à fila do buffer disponível 82 para que o cliente 40 realize outras solicitações de transação. Como aqui utilizado, os buffers 36 alocados na fila do buffer de resposta 88 podem ser considerados “indisponíveis” ou “ocupados”. A fila do buffer de resposta 88 também pode ser uma “fila virtual”, conforme explicado acima. Ademais, as modalidades da invenção podem incluir configurações em que o cliente 40 não pode realizar solicitações de transação concluídas copendentes em todos os buffers disponíveis 36 de seu respectivo espaço da memória 86, portanto, o número coletivo de buffers 36 alocado entre a fila do buffer de solicitação 84 e a fila do buffer de resposta 88 não pode exceder o número de buffers 36 solicitados pelo cliente 40. [026] Nestas configurações, o espaço da memória unidirecional 80 pode proporcionar uma comunicação unidirecional, por exemplo, durante as transações somente leitura, ao passo que o espaço da memória bidirecional 86 pode proporcionar a comunicação bidirecional, por exemplo, durante as operações de leitura e gravação. As modalidades da invenção podem incluir configurações em que o cliente 40 está habilitado a transação, e o servidor 50 pode responder com uma transação correspondente. Qualquer número de espaços da memória unidirecional e bidirecional 80, 86 pode estar incluído nas modalidades da invenção, e definido pelas transações solicitadas, conforme explicado acima. [027] Os mecanismos para comunicação entre pelo menos um cliente 40 e pelo menos um servidor 50 através do acesso aos dados da mensagem no buffer 36 da memória compartilhada 22 estão descritos em referência à Figura 5. Na Figura 5, apenas um único cliente 40 e o espaço da memória endereçável correspondente 57 são ilustrados a título de concisão e melhor compreensão. As modalidades da invenção podem incluir uma pluralidade de clientes 40 e seus respectivos espaços de memória 57, cada um deles executando mecanismos similares. Adicionalmente, para fins ilustrativos, a pluralidade de buffers 36 mostrada exibe diferentes estados de classificação, inclusive os estados ocupado 44 e desocupado 46. Nestes exemplos, um buffer “ocupado” 44 pode ser “controlado” pelo cliente 40 ou pode ser “controlado” pelo servidor 50, onde “controle” indica a capacidade do respectivo controlador de manipular diretamente os dados da mensagem no buffer 36. A posse pode ser controlada e/ou gerenciada, por exemplo, pelo cliente 40 ou pode ser alocada e/ou gerenciada pelo ponteiro de acesso ativo 42 do cliente. O cliente 40 e/ou ponteiro de acesso ativo 42 direciona o acesso para a pluralidade de buffers 36 em função da solicitação de transação de dados. [028] Por conseguinte, um primeiro buffer 58 foi identificado como um buffer ocupado 44, e é controlado pelo cliente 40, por meio de uma primeira comunicação. Quando o cliente 40 tiver concluído a transação, ou uma porção da transação, com o primeiro buffer, o cliente 40 pode definir o buffer, por exemplo, para “solicitação pendente”, para indicar que uma transação é exigida pelo servidor 50, e cessar a primeira comunicação 64. Independentemente da transação com o servidor 50, se o cliente 40 solicitar uma nova transação, o ponteiro de acesso ativo 42 gerenciará a comunicação do cliente 40 identificando um segundo buffer 60 disponível para transações, e sinalizando para o próximo buffer 36 disponível (por exemplo, desocupado), mostrado como um segundo buffer 60. O cliente 40 pode então se comunicar com o segundo buffer 60 por meio de uma segunda comunicação 66, e o segundo buffer 60 terá um estado ocupado 44 (não mostrado). O cliente agora realizará a segunda transação pretendida nos dados armazenados no segundo buffer 60. Mediante nova solicitação de transação por aquele mesmo cliente 40, o mecanismo repete, de modo que a solicitação da transação ingressante pelo cliente 40 pode acessar um buffer desocupado 44, conforme identificado pelo cliente 40 e/ou ponteiro de acesso ativo 42. [029] O mecanismo ilustrado na Figura 6 constrói o mecanismo mostrado na Figura 5. Neste exemplo, o cliente 40 estava executando, por exemplo, uma transação de leitura/gravação no primeiro buffer 58, concluiu a transação e definiu o buffer 58, por exemplo, para “solicitação pendente” a fim de indicar que uma transação é exigida pelo servidor 50, e que agora está executando uma transação no segundo buffer 60. [030] O servidor 50 pode realizar transações para diversos clientes 40 de acordo com um escalonamento. Por exemplo, o servidor 50 pode estar realizando transações para clientes com base em um escalonamento round-robin, esquema primeiro a entrar, primeiro a sair, esquema último a entrar, primeiro a sair, escalonamento sequencial, escalonamento qualidade do serviço, escalonamento sincronizado onde cada cliente 40 tem um slot de tempo definido para interagir, ou uma combinação desses. Algoritmos e/ou métodos de escalonamento adicionais podem ser incluídos para lidar com diversas transações do cliente 40. [031] No exemplo ilustrado, quando o servidor 50 tiver determinado o cliente 40 que deve ser atendido, o servidor 50 pode primeiramente consultar a caixa de correio 32 e/ou a lista de referência 33 para identificar o cliente 40 (ilustrada como a comunicação 68). Em seguida, o servidor 50 pode consultar o cliente 40 e/ou o ponteiro de acesso ativo 42 do cliente para determinar se alguma transação é exigida pelo servidor 50 (ilustrada como a comunicação 70). Se nenhuma transação for exigida pelo servidor 50, o servidor 50 pode continuar operando de acordo com o escalonamento ou algoritmo, e pode, por exemplo, seguir para o próximo cliente 40 a ser atendido. No entanto, conforme descrito acima, o primeiro buffer 58 inclui uma transação a ser concluída pelo servidor 50. O cliente 40 e/ou o ponteiro de acesso ativo 42 identifica que o primeiro buffer 58 está pronto para o controle do servidor 50, podendo incluir, por exemplo, a localização do primeiro buffer 58 na memória compartilhada 22. [032] O ponteiro de acesso ativo 52 do servidor aponta então para o primeiro buffer identificado 58, e prossegue para fornecer a transação solicitada (ilustrada como a comunicação 72). Quando a transação solicitada do servidor 50 é concluída, o servidor 50 pode definir o buffer 58, por exemplo, para “resposta pendente” para outra transação, ou disponível (desocupado) para uma nova transação. O servidor pode então desacoplar a comunicação 72 do primeiro buffer 58, e repetir as comunicações descritas acimas para atender os buffers 36 adicionais do cliente 40, conforme a necessidade, ou conforme o escalonamento. Adicionalmente, as modalidades da invenção podem incluir um indicador de prioridade para priorização do serviço de buffers 36 específicos pelo servidor 50. [033] Adicionalmente, enquanto uma solicitação de transação para o servidor 50 é explicada, entende-se que um cliente 40 pode estar gerando transações que resultam em um enfileiramento de uma pluralidade de solicitações do servidor 50. Independentemente de como o servidor 50 responde a uma pluralidade de solicitações de transação do servidor, as modalidades da invenção podem incluir situações onde todos os buffers 36 estão ocupados enquanto um cliente 40 ou servidor 50 tenta solicitar uma transação adicional. Esse cenário é ilustrado na Figura 7, onde não existem buffers 36 disponíveis ou desocupados 46. Nessa circunstância, o cliente está realizando uma transação nos dados contidos em um buffer 36, e todos os demais buffers 36 estão ocupados 48, por exemplo, aguardando uma transação do servidor 50. Neste exemplo, o mecanismo para comunicação prevê que pelo menos um entre o ponteiro de acesso ativo 42, e/ou o buffer 36 atual do cliente 40 sempre responderá à respectiva solicitação de transação com uma indicação de falha da transação até que um buffer 36 adicional desocupado 46 esteja disponível. Nesse sentido, quando ocorre falha na solicitação de transação, o cliente 40 pode tentar novamente realizar a transação solicitada, transação essa, por exemplo, que pode ser concluída com sucesso em momento posterior, se um ou mais buffers 36 ficarem desocupados 46. Portanto, o mecanismo prevê o número de transações solicitadas pelo cliente 40, mais um (isto é, um “buffer extra” 36 opcional), de modo que, mesmo o cliente 40 sempre terá o buffer extra 36 para transações, ainda que sejam transações não concluídas, até que buffers adicionais 36 estejam disponíveis. Nas modalidades onde não são fornecidos buffers “extra”, os clientes 40 podem não ter um buffer 36 para tentar realizar a transação solicitada, e nenhuma transação será executada até que um ou mais buffers 36 sejam disponibilizados novamente. [034] Os mecanismos descritos anteriormente podem funcionar usando apenas transações de linguagem de montagem e máquina e/ou operações atômicas sem copiar os dados ao nível de projeto além da linguagem de montagem e máquina, por exemplo, sem copiar os dados ao nível do sistema operacional (por exemplo, “cópia zero”). O efeito técnico das modalidades da invenção, conforme descrito acima, inclui que a operação com cópia zero é obtida direcionando os clientes 40 e/ou servidores 50, usando os ponteiros de acesso ativos 42, 52, para os respectivos buffers 36 que incluem os dados da mensagem, de modo que os dados da mensagem jamais estão “fechados” ou “bloqueados” ao acesso por outros clientes 40 e/ou servidores 50. Adicionalmente, o uso de linguagem de montagem e máquina permite operações de “troca atômica” de referências, em que a atualização é concluída em um único ciclo atômico da operação, portanto não pode ser interrompida por outras atualizações nos dados e/ou buffer, já que outras atualizações não podem ser concluídas em um ciclo de operação menor que a troca atômica. Nesse sentido, as operações de troca garantem que a comutação da referência para um buffer 36 será absolutamente bem-sucedida ou falha e, portanto, não existe potencial para corrupção da referência em si, em decorrência, por exemplo, de interrupção da troca. O mecanismo opera nos limites entre cliente 40 e/ou processo 26, 28 e não se baseia na desabilitação de interrupções. [035] Ao usar instruções de linguagem de montagem e máquina e estruturas de dados básicas (por exemplo, listas simplesmente ligadas, referências básicas), os mecanismos fornecem comunicações de dados assíncronas ínterprocesso entre pelo menos um servidor 50 e pelo menos um cliente 40, em uma memória compartilhada 22, usando uma troca de dados de cópia zero, permitindo acesso “sem cadeado”, ou “sem bloqueio” aos dados acessíveis sem a configuração complexa de prioridade do processo, ou sem os fenômenos de “inversão de prioridade”, onde o acesso prévio a um processo de menor prioridade bloqueia os dados e não “libera” seu acesso mesmo quando um processo de prioridade mais alta solicita acesso. Na realidade, como as operações que utilizam instruções de máquina tendem para “o primeiro para os dados vence”, os processos com prioridade mais alta podem sempre realizar suas operações antes de todos. Adicionalmente, os mecanismos conferem acesso “sem espera” para dos dados acessíveis que podem ser realizados ao nível de processo, não apenas ao nível de thread. [036] As modalidades da invenção podem ainda utilizar os mecanismos anteriormente descritos fornecendo interfaces programáveis de aplicação (APIs) para acessar os mecanismos ao nível do sistema operacional (ou ao nível da aplicação, etc.) por meio das APIs. O efeito técnico é que as modalidades descritas acima permitem que o método de cópia zero impeça fechamento de dados, bloqueio de dados, e/ou inversão de prioridade. [037] Os mecanismos descritos anteriormente são adicionalmente organizados e configurados para que o slot de correio 32 seja capaz de alocar diversas solicitações de transação do cliente 40 e/ou servidor 50, mesmo quando o número de solicitações de transação está acima do esperado ou pretendido, ou quando gerados em taxa mais acelerada do que a capacidade do servidor em responder. Ademais, o mecanismo descrito pode fornecer um ataque de recusa ao serviço, em que um ou mais clientes tentam tornar indisponível a seus usuários pretendidos um recurso de máquina ou rede saturando o servidor-alvo com solicitações de transação para que não consiga fornecer o serviço pretendido. Os ataques de recusa ao serviço podem tentar monopolizar os recursos do servidor 50, do cliente 40, e/ou do buffer 36, o que pode incluir largura de banda, capacidades de processamento, ou habilidade em responder às transações de prioridade, ou podem obstruir ou reduzir o serviço pretendido, ou pior ainda, causar falha do servidor-alvo ou do recurso-alvo. No entanto, em qualquer tentativa de monopolização de um recurso do mecanismo descrito acima, a combinação opcional das falhas das solicitações de transação do buffer extra 36, junto com o escalonamento do servidor 50, impedirão esse tipo de ataque de recusa ao serviço, sem o qual as solicitações de transação podem ocorrer sem consumo de recursos, conforme descrito acima, e sem fechar ou bloquear os respectivos dados. [038] Uma vantagem adicional que pode ser realizada nas modalidades descritas acima é que tais modalidades impedem o baixo desempenho dos recursos do sistema resultante dos esforços de cópia de dados não ao nível de linguagem da máquina. Ademais, as modalidades da invenção reduzem o número de cópias necessárias utilizando referências e buffers, conforme descrito acima. Outra vantagem das modalidades descritas anteriormente inclui um mecanismo interno de substituição de dados antigos nos buffers e, portanto, não requer qualquer tipo de esquema de gerenciamento de dados da “coleta de lixo”. Ademais, o típico compartilhamento de dados de um servidor para um ou mais clientes é efetuado criando um armazenamento de dados global e protegendo esse armazenamento por meio de semáforos (isto é, valores de controle do acesso como indicadores bloqueados/não bloqueados), por exemplo, ao nível do sistema operacional, qualquer outra mutex ou proteções de bloqueio de dados (por exemplo, interrupções de dados, etc.), os quais podem ser dispendiosos em termos de tempo de processamento, em especial quando os armazenamentos de dados são volumosos. Isso torna as operações de acesso desbloqueadas mais eficientes e mais rápidas, como aqui descrito. Ademais, os sistemas operacionais não fornecem tipicamente um controle de semáforo entre os processos, somente entre os threads contidos em um processo. [039] Outras vantagens possíveis para realização nas modalidades descritas acima incluem o fato de que o projeto do slot de correio inclui a flexibilidade de se manter os processos fracamente acoplados, de que requer pouca coordenação, e dispensa uma “fase inicial em etapas” (isto é, os processos, o cliente, e/ou os servidores podem ficar online a qualquer momento). Adicionalmente, a implantação das APIs descritas acima pode resultar em custos reduzidos para o desenvolvimento do sistema, e margens de desempenho, em hardware similar, mais altas do que com os diferentes métodos de cópia. [040] Na medida ainda não descrita, as diferentes características e estruturas das várias modalidades podem ser usadas em combinação entre si na forma desejada. O fato de uma característica não estar ilustrada em todas as modalidades não significa que não possa existir, mas que sua ilustração foi abolida a título de concisão da descrição. Portanto, as várias características das diferentes modalidades podem ser misturadas e combinadas na forma desejada para formar novas modalidades, não importando se as descrições das novas modalidades foram relatadas de forma expressa. Todas as combinações ou permutas das características aqui descritas estão compreendidas no presente relatório descritivo. [041] Esta descrição por escrito faz uso de exemplos para revelar a invenção, inclusive o seu melhor modo de execução, e habilita qualquer indivíduo versado na técnica à sua prática, inclusive produzindo e utilizando qualquer dispositivo ou sistema e executando qualquer método incorporado. O escopo patenteável da invenção é definido por suas reivindicações, podendo agregar outros exemplos que venham a ocorrer aos indivíduos versados na técnica. Os exemplos adicionais estão integrados ao escopo das reivindicações se dotados de elementos estruturais não divergentes da linguagem literal das reivindicações, ou se incluírem elementos estruturais equivalentes com diferenças insignificantes em relação à linguagem literal empregada nas reivindicações.

Claims (15)

1. MECANISMO PARA COMUNICAÇÃO entre pelo menos um cliente e pelo menos um servidor através do acesso aos dados da mensagem em uma memória compartilhada, caracterizado pelo fato de que compreende: uma alocação dos dados na memória compartilhada em pelo menos um slot de correio, a alocação sendo acessível por um endereço constante predeterminado, e um conjunto de buffers para cada cliente do pelo menos um cliente para efetuar solicitações de transação, e em que cada buffer pode ser controlado tanto pelo respectivo cliente quanto pelo servidor; pelo menos um slot de correio contendo referências que identificam o pelo menos um cliente e o pelo menos um servidor; pelo menos um cliente tendo um ponteiro de acesso ativo que habilita o pelo menos um cliente a manipular diretamente os dados da mensagem por meio de um buffer controlado pelo cliente; e pelo menos um servidor tendo um ponteiro de acesso ativo que habilita o pelo menos um servidor a manipular diretamente os dados da mensagem por meio de um buffer controlado pelo servidor; em que os ponteiros de acesso ativos são alocados entre os buffers usando apenas operações atômicas sem copiar os dados ao nível do sistema operacional.

2. MECANISMO, de acordo com a reivindicação 1, caracterizado pelo fato de que o mecanismo é um sistema de gerenciamento de voo.

3. MECANISMO, de acordo com a reivindicação 1, caracterizado pelo fato de que pelo menos um slot de correio e o conjunto de buffers são previamente definidos durante a inicialização da memória compartilhada.

4. MECANISMO, de acordo com a reivindicação 1, caracterizado pelo fato de que a solicitação de transação compreende pelo menos uma solicitação entre ler os dados, ou gravar novos dados no buffer.

5. MECANISMO, de acordo com a reivindicação 4, caracterizado pelo fato de que pelo menos uma transação é alocada a um espaço da memória unidirecional que compreende pelo menos uma fila do buffer disponível e uma fila do buffer de solicitação.

6. MECANISMO, de acordo com a reivindicação 4, caracterizado pelo fato de que pelo menos uma transação é alocada a um espaço da memória bidirecional que compreende pelo menos uma fila do buffer disponível, uma fila do buffer de solicitação, e uma fila do buffer de resposta.

7. MECANISMO, de acordo com a reivindicação 1, caracterizado pelo fato de que o número de buffers é igual a pelo menos o número de transações solicitadas pelo respectivo cliente, mais um buffer extra.

8. MÉTODO PARA COMUNICAÇÃO entre pelo menos um cliente e um servidor através do acesso aos dados da mensagem em uma memória compartilhada, caracterizado pelo fato de que o método compreende: alocar os dados na memória compartilhada em pelo menos um slot de correio; designar um único endereço predeterminado para acessar cada pelo menos um slot de correio; alocar diversos buffers para cada cliente entre o pelo menos um cliente, cada buffer sendo controlável pelo cliente ou sendo controlável pelo servidor, o número de buffers sendo igual ao número de transações solicitadas pelo respectivo cliente; e alocar um ponteiro de acesso ativo do cliente do um buffer controlado pelo cliente para alterar o controle do buffer controlado pelo cliente para um buffer controlado pelo servidor que habilita o servidor a manipular diretamente os dados da mensagem por meio de um ponteiro de acesso ativo do servidor; em que os dados da mensagem são acessados por meio de ponteiros de acesso ativos para os buffers sem copiar os dados da mensagem ao nível do sistema operacional.

9. MÉTODO, de acordo com a reivindicação 8, caracterizado pelo fato de que a alocação dos dados em pelo menos um slot de correio, a designação de um único endereço predeterminado, e a alocação do número de buffers para cada pelo menos um cliente ocorre durante a inicialização da memória compartilhada.

10. MÉTODO, de acordo com a reivindicação 8, caracterizado pelo fato de que o acesso aos dados da mensagem compreende pelo menos uma ação entre ler os dados ou gravar novos dados no buffer.

11. MÉTODO, de acordo com a reivindicação 10, caracterizado pelo fato de que pelo menos uma transação é efetuada em um espaço da memória unidirecional que compreende pelo menos uma porção do estado e uma porção de dados da mensagem.

12. MÉTODO, de acordo com a reivindicação 10, caracterizado pelo fato de que pelo menos uma transação é efetuada em um espaço da memória bidirecionai que compreende pelo menos uma fila do buffer disponível, uma fila do buffer de solicitação, e um buffer de resposta.

13. MÉTODO, de acordo com a reivindicação 8, caracterizado pelo fato de que compreende adicionalmente iniciar uma nova solicitação de transação do cliente em um respectivo buffer desocupado controlado pelo cliente.

14. MÉTODO, de acordo com a reivindicação 8, caracterizado pelo fato de que o número de buffers é igual pelo menos ao número de transações solicitadas pelo respectivo cliente, mais um buffer extra.

15. MÉTODO, de acordo com a reivindicação 14, caracterizado pelo fato de que a nova solicitação de transação do cliente falhará quando todos os buffers do respectivo cliente estiverem ocupados.