BR112014010348B1 - Método e aparelho para migração de um detector de evento e sistema de computação distribuído para a migração de um detector de evento. - Google Patents

Método e aparelho para migração de um detector de evento e sistema de computação distribuído para a migração de um detector de evento. Download PDF

Info

Publication number
BR112014010348B1
BR112014010348B1 BR112014010348-8A BR112014010348A BR112014010348B1 BR 112014010348 B1 BR112014010348 B1 BR 112014010348B1 BR 112014010348 A BR112014010348 A BR 112014010348A BR 112014010348 B1 BR112014010348 B1 BR 112014010348B1
Authority
BR
Brazil
Prior art keywords
event
node
input events
events
input
Prior art date
Application number
BR112014010348-8A
Other languages
English (en)
Other versions
BR112014010348A2 (pt
Inventor
Michael PHILIPPSEN
Christopher Mutschler
Original Assignee
Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V. filed Critical Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V.
Publication of BR112014010348A2 publication Critical patent/BR112014010348A2/pt
Publication of BR112014010348B1 publication Critical patent/BR112014010348B1/pt

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4843Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485Task life-cycle, e.g. stopping, restarting, resuming execution
    • G06F9/4856Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/542Event management; Broadcasting; Multicasting; Notifications
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083Techniques for rebalancing the load in a distributed system
    • G06F9/5088Techniques for rebalancing the load in a distributed system involving task migration

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Debugging And Monitoring (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)
  • User Interface Of Digital Computer (AREA)

Abstract

aparelho, método e programa de computador para migração de um processo de detector de evento. a presente invenção refere-se a um conceito para migração de um detector de evento de um primeiro nó (n1) para um segundo nó (n2), onde um detector de evento processa eventos de entrada (e; a, b, c) para a geração de um evento de saída (d), onde cada eventos de entrada tem associado um atraso de evento individual correspondente a um tempo de propagação do evento de entrada para o primeiro nó (n1). compreende a transferência (112; 312) do primeiro nó (n1) para o segundo nó (n2) de informação sobre atrasos de eventos correspondentes aos eventos de entrada (e; a, b, c) no primeiro nó (n1); a transferência (114; 314) de um conteúdo do detector de evento a partir do primeiro nó (n1) para o segundo nó (n2), para a obtenção de um detector de evento migrado no segundo nó; o encaminhamento (116; 316) da pluralidade de eventos de entrada (e; a, b, c) do primeiro nó (n1) para o segundo nó (n2); o recebimento (122) no segundo nó (n2) da pluralidade de eventos de entrada (e; a, b, c).

Description

[0001] A presente invenção refere-se geralmente a redes de dados 1. em particular, a aparelhos e métodos para a transferência ou a migração de detectores de evento entre diferentes nós de um sistema de computação distribuído.
Antecedentes
[0002] As redes de sensor, tais como, por exemplo, redes de sen sor sem fio, têm uma faixa ampla de aplicações. Por exemplo, as redes de sensor sem fio de várias tecnologias podem ser usadas para fins de localização, tal como a localização de seres humanos e/ou outros objetos. Aqui, “localização” significa a detecção ou a determinação de uma localização ou posição geográfica. Alguns sistemas especializados de localização ou rastreamento de posição podem ser usados para a localização de jogadores e outros objetos (por exemplo, uma bola) em eventos esportivos, por exemplo, futebol, futebol americano, rúgbi, tênis, etc.
[0003] Com o uso de dados acumulados de localização geográfica ou posicionamento de jogadores e/ou uma bola, é possível derivar uma informação estatística relacionada ao evento esportivo inteiro, por exemplo, uma partida de futebol, ou relacionada a times ou jogadores individuais. Essa informação estatística derivada pode ser interessante por várias razões. Por um lado, há vários interesses comerciais, já que certas estatísticas e sua análise podem ser de relevância em particular para espectadores em um estádio e/ou na frente de um aparelho de televisão em casa. Daí a provisão de certas estatísticas pode atrair mais interesse em eventos esportivos. Por outro lado, os dados estatísticos derivados dos dados de posicionamento brutos podem ser usados, da mesma forma, para fins de treinamento. Aqui, um oponente e/ou o comportamento do próprio time podem ser analisados, bem como a performance e/ou a condição de saúde de jogadores individuais.
[0004] Os sistemas mencionados anteriormente de localização ou rastreamento de posição podem ser baseados em várias tecnologias. Por exemplo, uma informação de localização pode ser determinada com base na avaliação de sinais de rádio sem fio e/ou campos magnéticos. Para esta finalidade, transmissores e/ou receptores, geralmente também denotados como sensores, podem ser postos nos objetos individuais (por exemplo, jogadores, bola, etc.) para serem localizados pelo sistema. Dispositivos correspondentes de transmissão e/ou de recepção também podem ser montados em localizações predeterminadas em torno de uma área geográfica de interesse, por exemplo, como um campo de futebol. Uma avaliação de intensidades de sinal, tempos de propagação de sinal e/ou fases de sinal, apenas para denominar umas poucas técnicas alternativas possíveis, então pode levar a fluxos de dados de sensor indicativos da posição ou localização geográfica de jogadores individuais ou objetos em instantes de tempo diferentes. Tipicamente, uma amostra de dados de localização está associada a uma estampa de tempo indicando em qual tempo um objeto foi localizado na posição ou localização geográfica observada ou detectada. Com esta informação combinada, dados cinemáticos, como velocidade vetorial (velocidade escalar), aceleração, etc. podem ser providos da mesma forma, além dos dados de localização compreendendo, por exemplo, coordenadas x, y e z. Na sequência deste relatório descritivo, os dados de localização e/ou cinemáticos entregues pelo sistema de sensor de localização também será referido como dados brutos (de sensor).
[0005] Em um exemplo em particular de um sistema de rastrea- mento sem fio, pessoas ou objetos podem ser equipados com transmissores mínimos, os quais podem ser embutidos em calçados, uniformes e bolas, e cujos sinais são capturados por um número de antenas postas em torno de uma área sob observação, tal como, por exemplo, um campo de futebol. As unidades de receptor processam os sinais coletados e determinam seus tempos de chegada (ToA). Com base em um cálculo das diferenças de atraso de propagação, cada posição de transmissor é determinada continuamente. Além disso, uma rede de computador integrada com o sistema de rastreamento sem fio pode analisar os dados de posição ou de sensor, de modo a se detectarem eventos específicos. A operação na banda de 2,4 ou 5 GHz, o sistema de rastreamento é globalmente de licença livre.
[0006] Com base nos fluxos de dados de sensor brutos extraídos a partir do sistema de localização ou rastreamento de posição, os assim denominados “eventos” podem ser detectados. Desse modo, um evento ou um tipo de evento pode ser definido para ser uma ocorrência instantânea de interesse em um ponto de tempo e pode ser definido por um ID de evento único. Em geral, um evento está associado a uma mudança na distribuição de uma quantidade relacionada que pode ser detectada. Uma instância de evento é uma ocorrência instantânea de um tipo de evento em um ponto distinto no tempo. Um evento pode ser um evento primitivo, o qual é diretamente baseado em dados de sensor (dados cinemáticos) do sistema de rastreamento, ou um evento compósito, o qual é baseado em outros eventos previamente detecta-dos, ao invés disso. Quer dizer, um evento compósito não é diretamente dependente de dados de sensor brutos, mas de outros eventos. Em aplicações de jogo com bola, um evento pode ser, por exemplo, “o jogador X atinge a bola”, ou “o jogador X está de posse da bola”. Eventos mais complicados podem ser, por exemplo, “saída pela lateral” ou “falta”. Cada instância de evento pode ter três estampas de tempo: uma estampa de tempo de ocorrência, uma de detecção e uma de chegada. Todas as estampas de tempo estão no domínio de tempo discreto direto. A estampa de tempo de ocorrência ts é o tempo quando o evento realmente aconteceu, a estampa de tempo de detecção dts é o tempo quando o evento foi detectado por um detector de evento, e a estampa de tempo de chegada ats é o tempo quando o evento foi recebido por um nó de sistema de processamento de evento (EPS) em particular. As estampas de tempo de ocorrência e de detecção são fixadas para uma instância de evento em qualquer nó de recepção, ao passo que a estampa de tempo de chegada pode variar em nós diferentes na rede.
[0007] A detecção de eventos (processamento de evento comple xo, CEP) com base em fluxos de dados de sensor subjacentes criou um interesse aumentado nas comunidades de sistemas de banco de dados e distribuídos nos últimos poucos anos. Uma faixa ampla e números cada vez mais crescentes de aplicações hoje em dia, incluindo aplicações como monitoração de rede, comércio eletrônico, cuidados com saúde, análise financeira e segurança ou a supervisão mencionada anteriormente de evento esportivo, baseiam-se na capacidade de processar consultas por fluxos de dados que de modo ideal assumem a forma de uma série ordenada no tempo de eventos. A detecção de evento denota o processamento plenamente automatizado de dados brutos de sensor e/ou eventos sem a necessidade de intervenção humana, já que, em muitas aplicações, a vasta quantidade de dados de sensor suprida e/ou de eventos não pode mais ser capturada ou pro-cessada por um ser humano. Por exemplo, se variações de velocidade alta ou de um objeto de esporte, por exemplo, umas bolas forem para serem esperados, os dados brutos de sensor (rastreamento de localização ou posição) terão que ser determinados a uma taxa de dados suficientemente alta pela rede de sensor (sem fio) subjacente. Adicio- nalmente, se houver um número alto de jogadores e/ou objetos (por exemplo, em futebol, há 22 jogadores e uma bola) a serem rastreados, a quantidade de amostras de dados em geral de localização e cinemáticos por segundo pode se tornar proibitivamente alta, em particular com respeito a exigências de processamento de evento em tempo real.
[0008] Daí, mesmo se dados de sensor brutos e/ou de evento fo rem analisados e sinalizados de forma plenamente automática, ainda poderá haver informação demais, o que possivelmente não é mesmo de qualquer interesse em sua totalidade. No futuro, este problema ficará cada vez pior, conforme cada vez mais dispositivos serão equipados com sensores, e a possibilidade de prover seus dados de sensor determinados para redes públicas, tais como a Internet para (por exemplo, dados de clima ou temperatura determinados por dispositivos sem fio, como smartphones). Por esta razão, a quantidade de dados de sensor a serem processados adicionalmente em certos eventos de interesse crescerá rapidamente. Uma detecção de evento automatizada pode prover remédio para isto ao se tentar a agregação de dados brutos de sensor pedaço por pedaço e para a determinação de eventos mais abstratos e interdependentes, o que pode transferir bem mais informação do que os dados brutos de sensor em si. Por exemplo, além dos exemplos mencionados anteriormente relacionados a futebol, esses eventos determinados poderiam incluir “o carro X está localizado no cruzamento Y”, ou “engarrafamento de trânsito na rota X”.
[0009] O problema que surge em uma detecção automatizada de evento é a potência requerida de computação para execução de uma detecção de evento em fluxos de dados de sensor e/ou de evento possivelmente paralelos de forma maciça - e tudo isto segundo exigências de processamento pelo menos quase em tempo real. Este problema pode ser resolvido pela paralelização de detectores de evento, o que, por exemplo, pode rodar em nós de rede diferentes (isto é, distribuídos) em uma rede de computador, o que pode se comunicar, por exemplo, via uma Ethernet. Desse modo, um evento automaticamente extrai certo evento de interesse a partir de um fluxo de dados de evento ou sensor de acordo com as especificações de evento de um usuário. Os detectores de evento individuais podem ser distribuídos por nós diferentes de rede de uma rede de dados, em que diferentes detectores de evento se comunicam usando dados de eventos e/ou dados de sensor viajando através da rede usando rotas e ramificações diferentes de rede. Desse modo, dados brutos de sensor e/ou evento podem ser transportados em pacotes de dados de acordo com algum protocolo de transporte, como, por exemplo, UDP (protocolo de datagrama de usuário), TCP (protocolo de controle de transmissão) / IP (protocolo de Internet), etc. Este conceito, contudo, causa novos problemas com respeito a uma carga computacional possivelmente desequilibrada dentre diferentes nós de rede e com respeito à sincronização de fluxos de dados de evento na rede. Sem contramedidas adequadas, as cargas computacionais dentre diferentes nós de rede são desequilibradas e fluxos de dados de sensor e/ou de evento indi-vidual podem atingir um detector de evento fora de sua ordem temporal e, desse modo, levar a falsos resultados detectados.
[00010] Vamos olhar para um cenário de exemplo de futebol, em que uma pluralidade de detectores de evento operando automaticamente em paralelo é suposta, para a detecção de um passe do jogador A para o jogador B. De modo a se detectar o evento de “passe”, a sequência de evento precedente a seguir é requerida: 2. “o jogador A está de posse da bola”, 3. “o jogador A chuta a bola”, 4. “a bola deixa o jogador A”, 5. “a bola se aproxima do jogador B”, 6. “o jogador B atinge a bola”.
[00011] A detecção de evento para o evento “o jogador X chuta a bola” pode ser com base na sequência de evento “jogador X perto da bola” e um pico de aceleração detectado da bola. Há as alternativas a seguir para a regulagem de um detector de evento automatizado para o referido evento “o jogador X chuta a bola”.
[00012] Nós podemos esperar por eventos requeridos individuais - um após o outro. Se nós tivéssemos visto todos os eventos requeridos na ordem (temporal) correta (aqui, quaisquer critérios de abortar são desconsiderados, em nome da simplicidade), poderemos dizer que nós vimos ou experimentamos um passe. Contudo, para aplicações complexas, a detecção de todos os eventos requeridos não necessariamente ocorre em um único nó de rede ou uma CPU (unidade de processamento central) devido à paralelização de detectores de evento. Por esta razão, não é necessariamente garantido que eventos requeridos individuais atinjam o detector de evento na ordem requerida correta. Isto pode ser, por exemplo, devido a uma instabilidade de rede, uma carga de CPU variando e/ou não equilibrada ou uma carga de rede aumentada. Por exemplo, considere um fluxo de evento consistindo em instâncias de evento e 1, e2, ... , en, com ek.ats < ek+i.ats, (1 < k < n), isto é, os eventos no fluxo de evento são classificados por seu tempo de chegada em ordem ascendente. Se qualquer evento ei 4 ej com 1 < i < j < n existir, de modo que ei.ts > ej.ts, então, o evento ej será denotado como um evento fora de ordem.
[00013] Daí, poderíamos tentar armazenar em buffer os eventos e, então, buscar o buffer para o padrão de evento correto. Mas qual tamanho de buffer deve ser usado? Se nós dissermos que um passe tem que ocorrer em no máximo 5 segundos, nós poderíamos considerar eventos em um período de tempo de no máximo 5 segundos após o primeiro evento relevante, até termos detectado o passe ou até abortarmos. Contudo, também é possível que o último evento relevante seja computacionalmente bastante complexo, o que requer um buffer adicional pequeno. Mas qual é o tamanho deste buffer adicional? E qual é o tamanho de buffer relacionado a detectores de evento compósito que requerem o evento de “passe” como um evento de entrada?
[00014] O algoritmo de folga K de S. Babu, U. Srivastava, e J. Wi- dom, “Exploiting k-constraints to reduce memory overhead in continuous queries over data streams,” ACM Trans. Database Systems, vol. 29, pp. 545-580, 2004, é uma solução bem conhecida para se lidar com eventos fora de ordem na detecção de evento. Uma folga K usa um buffer de comprimento K para garantir que um evento ei possa ser atrasado por no máximo K unidade de tempo (K tem que ser conhecido a priori). Contudo, em um sistema distribuído, os atrasos de sinalização de evento são dependentes de uma configuração inteira de sistema / rede, isto é, da distribuição dos detectores de evento, bem como da carga de rede e de CPU. Nem a configuração final de sistema, nem o cenário de carga podem ser previstos no momento da compilação.
[00015] Uma abordagem por M. Li, M. Liu, L. Ding, E. A. Runden- steiner, e M. Mani, “Event stream processing with out-of-order data arrival,” in Proc. 27th Intl. Conf. Distributed Computing Systems Workshops, (Washington, DC), pp. 67-74, 2007, armazena em buffer um evento ei pelo menos por um tempo tão longo quanto ei.ts + K < clk. Como não há um relógio global em um sistema distribuído, cada nó sincroniza seu relógio local pela regulagem dele para a maior estampa de tempo de ocorrência vista até aquele momento.
[00016] Uma unidade de ordenação que implementa a abordagem de folga K aplica uma janela deslizante com um dado K ao fluxo de entrada, atrasa os eventos de acordo com suas estampas de tempo, e produz um fluxo de saída ordenado de eventos. Contudo, um único K a priori fixo não funciona para detectores de evento distribuídos hierárquico. Como uma folga K leva K unidades de tempo para a geração de um evento compósito, um detector de evento em uma camada mais alta que também armazena em buffer K unidades, e espera pelo evento compósito, perde o referido evento. Os tempos de espera se somam ao longo da hierarquia de detector de evento.
[00017] M. Liu, M. Li, D. Golovnya, E. Rundensteiner, e K. Clay- pool,“Sequence pattern query processing over out-of-order event streams,” in Proc. 25th Intl. Conf. Data Engineering, (Shanghai, China), pp. 784-795, 2009, evitam esses problemas pela regulagem de um K individual para cada detector de evento. Cada Kn (n denotando o nível de hierarquia) deve ser regulado para um valor maior do que max(Kn-1), isto é, maior do que o atraso máximo de todos os eventos assinados. Desse modo, um evento assinado é um evento de interesse para o respectivo detector de evento. O detector de evento de nível de hierarquia n assina um evento de um nível de hierarquia mais baixo de modo a usá-lo como uma entrada para a detecção de um evento de hierarquia mais alta. Embora isto pareça bom em uma primeira olhada, escolher valores apropriados para todo Kj é difícil, específico de aplicação e topologia, e pode ser feito apenas após medições cuidadosas. Kj conservativos e excessivamente grandes resultam em buffers grandes com demandas altas de memória e em longos atrasos para CEP hierárquico (conforme os atrasos se somam). Kj grandes demais devem ser evitados. Teoricamente, para um sistema de finalidade geral, o menor / melhor Kj pode ser encontrado apenas por meio de medidas de tempo de rodada, já que as latências dependem da distribuição de detectores de evento e da topologia de rede subjacente concreta. Mais ainda, os melhores valores de Kj mudam no tempo de rodada, quando os detectores migram.
[00018] Com um dado fluxo de eventos entrando ei, uma ideia chave para suplantar os problemas mencionados anteriormente é executar estas medições de tempo de rodada pela comparação de uma estampa de tempo de ocorrência de evento ts com sua estampa de tempo de chegada ats. Quer dizer, as modalidades da presente invenção são baseadas na hipótese de que uma recuperação de uma ordem temporal original de eventos atingindo um detector de evento através de percursos de rede diferentes e, daí, experimentando atrasos de processamento e/ou de propagação diferentes δ(.) pode ser obtida pelo atraso dos eventos apropriadamente antes do encaminhamento ou da retransmissão deles para um detector de evento subsequente. O tempo no qual um evento é retransmitido para o detector de evento subsequente (fluxo normal) pode ser com base na estampa de tempo original do respectivo evento e os atrasos de processamento e/ou de propagação de todos os eventos de entrada requeridos pelo detector de evento subsequente, de modo a se determinar seu evento de saída.
[00019] De modo a garantir um valor de atraso comum requerido mínimo, isto é, para permitir uma retransmissão possivelmente rápida de (pelo menos) dois eventos, um tempo de saída para retransmissão de primeiro e segundo eventos de entrada para seu detector de evento de fluxo normal associado pode ser determinado com base no valor de sincronismo de primeiro e segundos eventos (do respectivo evento) e com base em um atraso máximo dos primeiro e segundo eventos. Desse modo, um atraso δ(.) de um evento pode ser devido a várias razões. Por exemplo, um atraso de evento no sistema de computação distribuído pode ser devido a diferentes condições de instabilidade em diferentes percursos de rede, ou devido a diferentes durações de processamento e/ou diferentes latências de rede. Em outras palavras, uma ordem de recepção dos primeiro e segundo eventos na entrada do compensador de atraso pode ser diferente de uma ordem de ocorrência original dos primeiro e segundo eventos, devido a diferentes condições de instabilidade, diferentes durações de processamento e/ou diferentes latências de rede.
[00020] Os atrasos de evento dos primeiro e segundo eventos, res-pectivamente, podem ser medidos ou determinados com base em um tempo de recepção / chegada dos primeiro e segundo eventos em uma unidade de ordenação, e com base em seus respectivos valores de sincronismo de evento associados refletindo as ocorrências de evento. Quando se denota um atraso de propagação ou de sinalização de um evento ei (i = 1, 2, ...) a partir de sua ocorrência ou tempo de detecção tevent,ei (i = 1, 2, ...) para a entrada do compensador de atraso por δ(.), a unidade de ordenação pode ser operável para a determinação de instâncias de tempo de saída tout,ei (i = 1, 2, .) para retransmissão dos primeiro e segundo eventos para o detector de evento subsequente, com base em tout,e1,e2 = tevent,e1,e2 + max(δ(e1), δ(e2))
[00021] onde max(.) denota o operador de máximo. Quer dizer, a unidade de ordenação pode ser operável para determinar um valor de atraso máximo tomado a partir do conjunto de atrasos de evento associados aos primeiro e segundo eventos. No caso em que há mais de dois eventos a serem retransmitidos pela unidade de ordenação, então, obviamente, a unidade de ordenação pode determinar o valor de atraso comum pela tomada do valor de atraso máximo a partir do conjunto de atrasos de evento associados a mais de dois eventos.
[00022] Devido a vários fatores, K = max(δ(e1), δ(e2)) pode mudar. Também, quando clk muda inesperadamente em um detector de evento, isto pode levar a chutes errados para K e, daí, a saídas detectadas erradas.
[00023] O primeiro problema mencionado anteriormente, isto é, um aumento súbito de Kj, é um evento raro, conforme atrasos de evento frequentes permanecem estáveis. Se isto ocorrer, não poderemos garantir uma ordenação correta em geral. Mas uma margem de segurança probabilística para atrasos pode ser provida para aliviar este problema. Em contraste, nós podemos evitar o segundo problema, isto é, mudanças inesperadas de clk. Uma ideia em que modalidade da presente invenção podem se basear é não mais regular o relógio para a maior estampa de tempo vista até agora em quaisquer eventos entrando, mas usar apenas um tipo designado de evento para a regula- gem de clk.
[00024] Uma mudança inesperada de clk pode ser evitada se regularmos um relógio de nó de rede apenas em certos tipos de eventos entrando. Embora a definição acima de eventos fora de ordem tenha identificados eventos que são atrasados, agora, usamos os valores de clk para postergar eventos que chegam cedo demais. Entre quaisquer duas atualizações de clk, eventos não postergados são ordenados de acordo com suas estampas de tempo. Mais formalmente, considere um fluxo de evento e 1, e2,..., en como antes. Assume-se que clk seja regulado apenas pelos eventos de tipo ID. Um evento ej é um evento fora de ordem, se não existir um ei, ek, com ei.id = ek.id = ID, de modo que ei.ts < ej.ts < ek.ts. O atraso de evento de ei pode ser dado por δ(e) = ek.ts - ej.ts.
[00025] A questão remanescente é qual tipo de evento pegar para a regulagem de clk. Quanto mais alta a frequência de ocorrência do tipo de evento capturado, menos eventos precisam ser postergados, menores são os valores K resultantes, e melhores são os atrasos medidos. Se houver uma escolha de tipos de eventos, aquele com o atraso mais estável e fixo será preferível, porque ele reflete melhor o tempo real. Caso contrário, se os eventos de um certo tipo variarem nos seus tempos de chegada, clk não se comportará de forma suave. Para au- mentar a frequência de atualização de relógio, ao invés de usar apenas um tipo de evento, é possível usar um conjunto de tipos de evento para a regulagem do relógio, desde que aqueles tipos de evento tenham os mesmos atrasos absolutos, por exemplo, se houver eventos de sensor a partir da mesma fonte. Eventos de sensor de taxa alta de dados com estampas de tempo precisas são excelentes candidatos.
[00026] Tomar eventos de sensor, isto é, dados brutos de sensor, como eventos estáveis de atualização de relógio, deixa-nos determinar um valor apropriado para K. Mas o primeiro problema de aumentos súbitos de K ainda está em aberto. Se K for pequeno demais, perderemos eventos ou os processamos fora de ordem, e, então, aumentaremos K para adaptação para futuros atrasos de evento. Com uma margem de segurança adicionada, isto é, um K ligeiramente maior, esses erros de detecção podem ser evitados. Ao invés de fixar K após um erro ter ocorrido, é possível superajustar K com a variação esperada de atrasos. Lembrando que K é definido como o atraso máximo de todos os eventos assinados de um detector de evento. A estimativa dos atrasos dos eventos em particular de forma mais exata resulta em um valor de K mais seguro. Para dar um chute melhor para o atraso que esperamos para um evento ei, é possível usar todas as medições recentes de atraso de ei, é possível usar todas as medições recentes de ei e determinar seu desvio padrão. O atraso chutado então é o atraso máximo de ei mais o produto do desvio padrão e de um fator de escalonamento X. À pode ser definido pelo arquiteto do sistema e tem influência sobre a probabilidade de K ser grande o bastante. Com esses valores de K, podemos ordenar os fluxos de evento de entrada, mesmo com atrasos de evento instáveis.
[00027] Contudo, se um valor de K crescer para um certo detector de evento, este fato permanecerá desconhecido para um detector de evento assinante mais adiante na hierarquia de detector. O detector de nível superior apenas notará uma mudança e um atraso potencialmente grande demais, quando o evento assinado é realmente gerado. Então, o K de nível superior pode ser pequeno demais para se evitar uma má detecção e um retroajuste de K. Mas o detector de nível superior poderia ter modificado seu K antes o bastante, se ele apenas tivesse sido informado mais cedo. Daí, sempre que K muda, é possível notificar os assinantes, de modo que eles possam modificar seus valores de K, se necessário. Por isso, é possível imediatamente enviar um pseudoevento com uma estampa de tempo adequada. O destinatário apenas pode usar um pseudoevento como esse para fins de configuração.
[00028] Agora, temos um K suficientemente bom e um relógio estável clk. Contudo, isto não produz ainda um fluxo de evento classificado ou ordenado. Precisamos de uma unidade de ordenação de evento que funcione em um fluxo fora de ordem para se prover uma entrada classificada para o detector subsequente. Uma unidade de ordenação como essa pode ser implementada como uma caixa preta, e pode ser montada apenas entre o fluxo de evento original e a entrada do detector de evento, de modo que não haja necessidade de modificação do detector de evento em si. O fluxo de saída da unidade de ordenação é uma sequência classificada de eventos com um atraso mínimo. Sempre que um evento de entrada é recebido (os pseudoeventos são igno-rados), é classificado em um buffer da unidade de ordenação, de acordo com sua estampa de tempo de ocorrência. Se eventos fora de ordem forem raros, uma classificação de inserção de novos eventos usualmente é apenas um empurrão simples e rápido para frente do buffer. Sempre que clk é atualizado e ei.ts + K < clk se mantém para alguns eventos de fim ei no buffer, aqueles ei podem ser emitidos para o fluxo de saída da unidade de ordenação, e o próximo evento de entrada pode ser processado.
[00029] Note que, usualmente, há mais de um detector de evento por máquina ou nó de rede, cada um dos quais podendo ter uma unidade de ordenação dedicada com um K adequado e específico de detector que apenas captura seus eventos assinados a partir do fluxo de evento principal.
[00030] Em um processamento de evento distribuído, pode ser necessário mover um detector de evento de uma máquina para uma outra no tempo de rodada. Isto pode ser causado por muitas razões, por exemplo, as máquinas podem precisar ser paradas para manutenção ou devido a falhas de sistema, ou as máquinas podem ficar sobrecarregadas ou mesmo exauridas e não podem realizar suas tarefas de processamento de evento rapidamente o bastante. Aquelas mudanças pode ser o resultado da dinâmica do ambiente analisado, por exemplo, negociações súbitas de ações.
[00031] Um trabalho relacionado sobre migração de tempo de rodada de processos ou objetos é principalmente feito na área de máquinas virtuais (VMs). Por exemplo, R. Bradford, E. Kotsovinos, A. Feldmann, e H. Schioberg, “Live wide-area migration of virtual machines including local persistent state”, in Proc. 3rd Intl. Conf. Virtual Execution Environments, (San Diego, CA), pp. 169-179, 2007, lidam com a transferência de estado de VM persistente local. Após uma migração, as conexões de rede estão sendo redirecionadas para o novo computador central, e comandos de antigas conexões são encami-nhados. A VM antiga é fechada tão logo todas as conexões antigas tenham terminado. Contudo, ambas as máquinas não apenas têm que rodar em paralelo enquanto comandos estão sendo encaminhados, mas a ordem em que aqueles comandos são recebidos pela rede é ignorada.
[00032] Um movimento de CR/TR de H. Liu, H. Jin, X. Liao, L. Hu, e C. Yu, “Live migration of virtual machine based on full system trace and replay”, in Proc. 18th ACM Intl. Symp. High Performance Distributed Computing, (Garching, Alemanha), pp. 101-110, 2009, usa uma tecnologia de ponto de checagem / recuperação e traço / replay para obter uma migração rápida de VMs. Os pontos de checagem a partir da VM de fonte são recuperados no destino, e traços de chamada a partir da fonte são reexecutados de modo que ambas as máquinas sejam consistentes. O tempo parado é significativamente mais baixo do que em abordagens prévias. Contudo os autores não consideram que a ordem de comandos entrando pode ser diferente no novo computador central.
[00033] A abordagem de V. Medina e J. M. Garcia,“Live replication of virtual machines”, in Proc. 10th WSEAS Intl. Conf. Software Engineering, Parallel and Distributed Systems, (Stevens Point, WI), pp. 1523, 2011, é similar ao Movimento de CR/TR, mas assume réplicas bem desde o começo. O usuário interage com uma VM, mas os comandos também são enviados para uma réplica, de modo que ambas as VMs sempre estejam sincronizadas. Quando a máquina antiga para de funcionar, o protocolo de lado de cliente envia os comandos para a VM replicada, e apresenta a resposta da réplica. Contudo, os comandos são redirecionados a partir do lado de clientes, o que significa que a ordenação pode ser diferente, após uma comutação para a réplica.
[00034] Nenhuma das abordagens considera a ordem de comandos entrando e/ou dados explicitamente. Isto é devido usualmente à fonte dos comandos, isto é, a estação de trabalho de usuário é estática e os comandos ainda são recebidos na ordem correta. Contudo, se lidarmos com VMs de usuário múltiplo, problemas poderão ocorrer se dois usuários tentarem modificar o mesmo arquivo. Na VM original, o comando do usuário A pode ser recebido primeiramente, ao passo que na VM migrada o comando de usuário B será recebido primeiramente. As VMs então estão fora de sincronização. As abordagens como de Movimento de CR/TR repetiriam o processo de descoberta e reexecu- ção nessas situações improváveis. Contudo, para uma detecção de evento, essas situações são prováveis, e uma migração nunca terminaria.
[00035] Daí é desejável melhorar o estado da técnica para migração de forma eficiente e segura de detectores de evento operando em eventos fora de ordem entrando a partir de um nó de rede para outro. Sumário
[00036] Para a detecção de eventos, tais como eventos primitivos e/ou compósitos, vários detectores de evento podem estar rodando em nós diferentes de um sistema de computação distribuído. Esses detectores de evento podem causar cargas diferentes em seus respectivos nós associados e/ou o sistema de computação distribuído inteiro, dependendo da condição do sistema e/ou dependendo da complexidade computacional do algoritmo subjacente de detector e/ou dos dados de sensor a serem analisados. Daí, em um cenário de instalações ou condições mudando de uma configuração de sistema original, uma distribuição original dos detectores de evento nos vários nós de rede poderia vir a ser subótima com respeito ao equilíbrio de carga computacional ou poderia mesmo levar a uma destruição do sistema de com-putação distribuído.
[00037] Esses desequilíbrios indesejáveis de carga podem ser con-trabalançados por modalidades da presente invenção. Por exemplo, se pelo menos um atraso de evento atingir um valor proibitivamente alto, isto poderá ser um indicador para um fato de que o detector de evento, a partir do qual o evento correspondente atinge um detector de evento de destino, está sobrecarregado ou experimenta alguns outros problemas. Em um cenário como esse, pode ser desejável transferir ou realocar o processo de detector de evento de fonte malicioso ou objeto para algum outro recurso de hardware do sistema de computação distribuído. Por exemplo, o processo ou objeto de detector de evento de fonte malicioso pode ser transferido ou migrado de seu nó atual para outro nó fisicamente separado e diferente do sistema de computação distribuído, o que tem mais recursos de hardware disponíveis.
[00038] É uma descoberta da presente invenção que a migração de um detector de evento de uma máquina para outra máquina leva a atrasos de evento diferentes dos eventos manipulados pelo detector de evento afetado. Quando um detector de evento é migrado de um primeiro nó de rede para um segundo nó de rede, os nós de fonte dos eventos assinados permanecem os mesmos, mas os atrasos de evento relacionados mudarão mais definitivamente. A menos que atrasos se retraiam para todos os eventos envolvidos, uma migração de detector de evento tímida provavelmente falhará, porque o detector de evento migrado (ou quaisquer detectores de evento em uma camada mais alta) não mais vê os eventos assinados em uma ordem correta, porque o valor de K que funcionou bem no primeiro nó (antigo) é pequeno demais para o segundo nó (novo) e os novos atrasos de evento resultantes.
[00039] Daí é um objetivo da presente invenção garantir eventos de entrada ordenados para o detector de evento migrado.
[00040] É uma descoberta da presente invenção que, para uma transferência de ponto a ponto de detector de evento cooperativa, o novo nó de um sistema de computação distribuído não apenas assina os eventos de entrada necessários a partir de seus nós de origem ou fonte, mas o nó antigo também encaminha aqueles eventos para o novo nó da mesma forma. O novo nó pode derivar a ordem correta de evento pela combinação de uma informação de atraso de eventos que cheguem ao novo nó ao longo de dois percursos, isto é, o percurso encaminhado (a partir dos nós de fonte através do nó antigo) e o percurso direto (a partir dos nós de fonte diretamente).
[00041] De acordo com um primeiro aspecto, é provido um método para a migração de um detector de evento (processo ou objeto) a partir de um primeiro nó (isto é, um nó antigo) de um sistema de computação distribuído para um segundo nó (isto é, um novo nó) do sistema de computação distribuído. O detector de evento processa uma pluralidade de eventos de entrada para a geração de pelo menos um evento de saída com base nos eventos de entrada. Cada um dos eventos de entrada tem associado a ele um atraso de evento correspondente a um tempo de propagação ou atraso do respectivo evento de entrada para o primeiro nó, em que o tempo de propagação pode ser considerado como uma diferença entre um tempo de ocorrência de evento e uma recepção de evento subsequente ou tempo de chegada do respectivo evento no primeiro nó. O método compreende uma etapa de transferência, do primeiro nó para o segundo nó, de uma informação sobre os atrasos de evento correspondendo à pluralidade de eventos de entrada no primeiro nó, uma etapa de transferência de um conteúdo (processo ou objeto) do detector de evento a partir do primeiro nó para o segundo nó, para a obtenção de um detector de evento migrado no segundo nó, uma etapa de encaminhamento da pluralidade de eventos de entrada a partir do primeiro nó para o segundo nó, uma etapa de recebimento, no segundo nó, da pluralidade de eventos de entrada encaminhados a partir do primeiro nó e, em paralelo, a partir de detectores de evento de origem associados à pluralidade de eventos de entrada, uma etapa de processamento (ordenado), no segundo nó, da pluralidade de eventos de entrada recebidos, com base na informação transferida nos atrasos de evento e com base nos atrasos de evento da pluralidade de eventos de entrada recebidos a partir dos detectores de evento associados.
[00042] De acordo com um aspecto adicional, também é provido um sistema de computação distribuído para a migração de um detector de evento de um primeiro nó do sistema de computação distribuído para um segundo nó do sistema de computação distribuído. O sistema de computação distribuído compreende o primeiro nó tendo um meio para a transferência, a partir do primeiro nó para o segundo nó, de uma informação sobre os atrasos de evento correspondendo à pluralidade de eventos de entrada no primeiro nó, um meio para a transferência de um conteúdo no detector de evento a partir do primeiro nó para o segundo nó, para a obtenção de um detector de evento migrado no segundo nó, e um meio para o encaminhamento da pluralidade de eventos de entrada a partir do primeiro nó para o segundo nó. O sistema de computação distribuído ainda compreende o segundo nó tendo um meio para o recebimento, no segundo nó, da pluralidade de eventos de entrada encaminhados a partir do primeiro nó, e, em paralelo, a partir dos detectores de evento de origem associados à pluralidade de eventos de entrada, um meio para o processamento, no segundo nó, da pluralidade de eventos de entrada recebidos com base na informação transferida sobre os atrasos de evento e com base nos atrasos de evento da pluralidade de eventos de entrada recebidos a partir dos detectores de evento associados.
[00043] As modalidades também proveem os primeiro e/ou segundo nós do sistema de computação distribuído.
[00044] Assim sendo, também é provido um primeiro método (para o primeiro nó) para a migração de um detector de evento a partir do primeiro nó para o segundo nó do sistema de computação distribuído. O método compreende uma etapa de transferência, a partir do primeiro nó para o segundo nó, de uma informação sobre atrasos de evento correspondentes à pluralidade de eventos de entrada no primeiro nó, uma etapa de transferência de um conteúdo ou estado do detector de evento a partir do primeiro nó para o segundo nó para a obtenção de um detector de evento migrado no segundo nó, e uma etapa de encaminhamento da pluralidade de eventos de entrada do primeiro nó para o segundo nó.
[00045] Também é provido um segundo método (do segundo nó) para a migração de um detector de evento do primeiro nó para o segundo nó do sistema de computação distribuído, que compreende uma etapa de recebimento, no segundo nó, da pluralidade de eventos de entrada encaminhados a partir do primeiro nó e, em paralelo, a partir dos detectores de evento de origem associados à pluralidade de eventos de entrada, e uma etapa de processamento, no segundo nó, da pluralidade de eventos de entrada recebidos com base na informação transferida sobre os atrasos de evento e com base nos atrasos de evento da pluralidade de eventos de entrada recebidos a partir dos detectores de evento associados.
[00046] Algumas modalidades compreendem circuitos de controle digitais instalados nos nós ou aparelhos. Um circuito de controle digital como esse, por exemplo, um processador de sinal digital (DSP) ou um circuito integrado específico de aplicação (ASIC), precisa ser programado de modo conforme. Daí, ainda outras modalidades também proveem um programa de computador tendo um código de programa para a execução das modalidades do método, quando o programa de computador é executado em um computador ou um processador digital.
[00047] De acordo com as modalidades, um detector de evento é para ser entendido como uma instância de um programa de computador que está sendo executado em um nó no sistema distribuído. Um detector de evento compreende o código de programa de programa de computador e sua atividade atual. O sistema distribuído pode ser uma rede de computador distribuída ou um processador de núcleo múltiplo, por exemplo. No caso de uma rede de computador, um nó, isto é, um nó de rede, pode compreender um dispositivo de computador ou uma unidade de processamento (por exemplo, uma CPU) do mesmo em comunicação com outros nós de rede via Ethernet, por exemplo, ou alguma outra forma de tecnologia de rede. Quer dizer, de acordo com um aspecto adicional da presente invenção, também é provido um sistema de computação para a determinação de eventos com base em pelo menos um fluxo de dados (brutos) de sensor. O sistema de computação distribuído provido, o qual pode ser uma rede de computador, compreende uma pluralidade de nós distribuídos, cada um tendo um detector de evento associado a ele, e pelo menos uma modalidade de um aparelho para migração de detectores de evento entre os nós distribuídos do sistema de computação distribuído.
[00048] O procedimento de transferência ou migração de processo de detector de evento pode ser realizado, por exemplo, com o auxílio de um sistema operacional (OS) controlando o sistema de computação distribuído. Um OS desse modo é para ser entendido como um conjunto de programas que gerencia recursos de hardware de computador do sistema distribuído, e provê serviços comuns para um software aplicativo, como os processos ou objetos de detector de evento, por exemplo. Esses serviços de OS também podem compreender a instanciação de funcionalidades, isto é, as funcionalidades para a criação de um processo e/ou uma instância de objeto, ao que um aparelho para migração pode ter acesso. Quer dizer, o aparelho para migração ou aparelho de migração pode compreender um meio para acesso a fun-cionalidades de instanciação de processo e/ou objeto de um sistema operacional controlando o sistema distribuído.
[00049] Em algumas modalidades, o sistema de computação distribuído pode ser acoplado a um sistema de localização para localização e/ou rastreamento de objetos em uma área geográfica pré-definida, em que o sistema de localização provê pelo menos um fluxo de dados de sensor para o sistema de computação distribuído, o fluxo de dados de sensor portando dados sendo indicativo de posições geográficas dos objetos localizados. O sistema de localização pode ser com base em uma rede de sensor sem fio, o que já foi descrito na porção introdutória neste relatório descritivo.
[00050] Um detector de evento pode compreender uma máquina de estado, o que pode ser entendido como um modelo de comportamento usado para o projeto de um programa de computador subjacente de processo de detector de evento. Uma máquina de estado é composta por um número (finito) de estados associados a transições, em que uma transição é um conjunto de ações que começa a partir de um estado e termina em outro estado (ou no mesmo). Uma transição é começada por um gatilho, em que um gatilho como esse pode ser, por exemplo, um evento primitivo ou compósito ou dados brutos de sensor introduzidos no detector de evento. Daí, de acordo com os aspectos da presente invenção, um detector de evento pode compreender uma máquina de estado e um conteúdo ou uma memória de processo de detector de evento pode refletir um estado atual da referida máquina de estado, como, por exemplo, variáveis individuais ou arranjos ou variáveis. Para processos de detector de evento, a máquina de estado pode ser uma máquina de estado baseada em software, por exemplo, uma máquina de estado de linguagem de modelagem unificada (UML).
[00051] Um benefício de modalidades pode ser visto na auto- organização de um sistema de computação distribuído de acordo com modalidades da presente invenção. Um sistema de computação distribuído como esse pode reagir em condições mutáveis de sistema pela transferência de detectores de evento entre nós de rede, de modo que o sistema distribuído ou a rede seja sempre capaz de executar um processamento de sinal de evento robusto e eficiente.
[00052] Usualmente, não é possível rodar o detector de evento antigo e o novo em paralelo, se uma sobrecarga de CPU ou um extravasamento de buffer tiver disparado a migração. Mais ainda, um encaminhamento do fluxo de dados completo a partir do nó antigo para o no vo nó é proibitivo, já que pode causar altas cargas de rede e sobrecargas de processamento por um longo tempo, se eventos em particular ocorrerem de forma esparsa. As modalidades proveem um conceito que permite a migração de detectores de evento no tempo de rodada e inicializa os valores de K de acordo com os atrasos de sincronismo no novo nó. A latência introduzida é desprezível e ambas as instâncias de nó antigo e novo, bem como detectores de nível superior veem eventos em ordem em qualquer tempo. O detector de evento antigo pode parar tão logo o estado tenha sido copiado, e um tempo de processamento de rede é mantido em um mínimo.
Breve Descrição das Figuras
[00053] Algumas modalidades de aparelhos e/ou métodos serão descritas a seguir a título de exemplo apenas, e com referência às figuras associadas, nas quais:
[00054] a figura 1 ilustra esquematicamente um fluxograma de um método de migração de um detector de evento rodando em um primeiro nó para um segundo nó de um sistema de computação distribuído, de acordo com uma modalidade;
[00055] as figuras 2a, b mostram configurações de exemplo antes e depois de uma migração de detector de evento;
[00056] a figura 3 mostra um quadro de sequência de mensagem para uma migração de detector de evento, de acordo com uma modalidade;
[00057] a figura 4 mostra atrasos de evento antes, durante e depois de uma migração de detector de evento; e
[00058] a figura 5 ilustra um pseudocódigo de exemplo para um programa de computador para adaptação de atraso e cancelamento de eco, de acordo com uma modalidade.
Descrição de Modalidades
[00059] Várias modalidades de exemplo serão descritas, agora, mais plenamente, com referência aos desenhos associados, em que algumas modalidades de exemplo são ilustradas. Nas figuras, as espessuras de camadas e/ou regiões podem ser exageradas, por clareza.
[00060] Assim sendo, embora modalidades de exemplo sejam capazes de várias modificações e formas alternativas, as modalidades das mesmas são mostradas a título de exemplo nas figuras e serão descritas, aqui, em detalhes. Deve ser entendido, contudo, que não há intenção de limitar as modalidades de exemplo para as formas em particular expostas, mas, ao contrário, as modalidades de exemplo são para cobertura de todas as modificações, equivalentes e alternativas caindo no escopo da invenção. Números iguais se referem a elementos iguais ou similares por toda a descrição das figuras.
[00061] Será entendido que, quando um elemento é referido como sendo “conectado” ou “acoplado” a outro elemento, pode ser conectado diretamente ou acoplado ao outro elemento ou elementos intervenientes podem estar presentes. Em contraste, quando um elemento é referido como estando “conectado diretamente” ou “acoplado diretamente” a outro elemento, não haverá elementos intervenientes presentes. Outras palavras usadas para a descrição da relação entre elementos devem ser interpretadas de uma forma similar (por exemplo, “entre” versus “diretamente entre”, “adjacente” versus “diretamente adjacente”, etc.).
[00062] A terminologia usada aqui é para fins de descrição de modalidades em particular apenas, e não é pretendida para limitação de modalidades de exemplo. Conforme usado aqui, pretende-se que as formas singulares “um”, “uma” e “a(o)” incluam as formas plurais da mesma forma, a menos que o contexto claramente indique de outra forma. Será entendido, ainda, que os termos “compreende”, “compreendendo”, “inclui” e/ou “incluindo”, quando usados aqui, especificam a presença de recursos declarados, integrantes, etapas, operações, elementos e/ou componentes, mas não impedem a presença ou a adição de um ou mais outros recursos, integrantes, etapas, operações, elementos, componentes e/ou grupos dos mesmos.
[00063] A menos que definido de outra forma, todos os termos (incluindo termos técnicos e científicos) usados aqui têm o mesmo significado, conforme comumente entendido por alguém de conhecimento comum na técnica à qual as modalidades de exemplo se referem. Será adicionalmente entendido que termos, por exemplo, aqueles definidos em dicionários comumente usados, devem ser interpretados como tendo um significado que é consistente com seu significado no contexto da técnica relevante e não serão interpretados em um sentido idealizado ou excessivamente formal, a menos que expressamente assim definido aqui.
[00064] A figura 1 ilustra esquematicamente um fluxograma de um método 100 para migração ou transferência de um detector de evento inicialmente rodando em um primeiro nó (antigo) ou uma máquina sem emendas para um segundo nó (novo) ou uma máquina de um sistema de computação distribuído, de acordo com uma modalidade da presente invenção.
[00065] O método de migração 100 compreende dois submétodos 110 e 120. As etapas de submétodo 110 podem ser associadas ao primeiro nó de rede, em que as etapas do segundo submétodo 120 podem ser associadas ao segundo nó de rede, de acordo com algumas modalidades. Contudo, isto não implica que os submétodos 110 e 120 são apenas executados pelos primeiro e segundo nós de rede, respectivamente. Ao invés disso, o método 110 pode ser parcialmente executado no segundo nó de rede, por exemplo. Conforme foi explicado antes, os primeiro e segundo nós do sistema de computação distri-buído podem ser, por exemplo, CPUs separadas. Essas CPUs sepa- radas podem estar localizadas em dispositivos de computação fisicamente diferentes ou podem corresponder a núcleos de processamento independentes diferentes de uma CPU de núcleo múltiplo, por exemplo.
[00066] A instância de detector de evento a ser migrada do primeiro nó para o segundo processa uma pluralidade de eventos de entrada assinados, de modo a se gerar pelo menos um evento de saída compósito com base nos eventos de entrada assinados. Quer dizer, os eventos de entrada são de um nível de hierarquia de evento mais baixo do que o evento de saída compósito gerado. Cada um dos eventos de entrada assinados tem associado a ele um atraso de evento individual δ(.), o que corresponde a uma diferença de tempo entre uma ocorrência de evento ou um tempo de detecção (ts ou dts) e um tempo de recepção ou chegada de evento subsequente (ats) do respectivo evento no primeiro nó.
[00067] O método 100 ou 110 compreende uma etapa 112 de transferência, a partir do primeiro nó para o segundo nó, de uma informação indicativa de atrasos de evento individuais (ou um máximo do mesmo) correspondente à pluralidade de eventos de entrada assinados no primeiro nó de rede. O método 100 ou 110 ainda compreende uma etapa 114 de transferência de um conteúdo e/ou um estado do detector de evento do primeiro nó para o segundo nó, de modo a se obter um detector de evento migrado no segundo nó. Conforme foi explicado antes, o detector de evento pode compreender uma máquina de estado finito compreendendo um número finito de estados e certas transições entre os referidos estados. Quer dizer, o conteúdo do detector de evento a ser migrado pode refletir um estado atual da máquina de estado de processador, como, por exemplo, variáveis individuais ou arranjos de variáveis.
[00068] Ainda, o método 100 ou 110 compreende uma etapa 116 de encaminhamento da pluralidade de eventos de entrada a partir do primeiro nó para o segundo nó. Conforme será evidente para a pessoa versada, as etapas 112, 114 e 116 podem ser realizadas ou executadas pelo primeiro nó em si. As etapas 112 a 116 em conjunto formam o método 110, o qual pode ser executado pelo primeiro nó de rede ou um dispositivo controlador central, o que pode controlar a interação computacional e/ou uma comunicação entre vários nós de rede.
[00069] O método de migração 100 ou o submétodo 120 ainda compreende uma etapa 122 de recebimento, no segundo nó de rede, da pluralidade de eventos de entrada encaminhados a partir do primeiro nó, e, em paralelo, a partir dos detectores de evento de origem associados à pluralidade de eventos de entrada. Quer dizer, na etapa 122, cada um da pluralidade de eventos de entrada é recebido no segundo nó através de dois percursos. Um primeiro percurso é um percurso de desvio levando de um detector de evento de origem ou de fonte de um respectivo evento de entrada via o primeiro nó de rede para o segundo nó de rede. O segundo percurso é um percurso direto levando de um detector de evento de origem de evento de entrada “di-retamente” para o segundo nó. Aqui, “diretamente” significa através da rede de computação distribuída sem tomar o desvio através do primeiro nó. A etapa 122 é seguida por uma etapa 124 de processamento ordenado, no segundo nó, a pluralidade de eventos de entrada recebidos com base na informação transferida sobre os atrasos de evento individuais (ou o máximo do mesmo) vindo a partir do primeiro nó e com base em novos atrasos de evento individuais da pluralidade de eventos de entrada diretamente recebidos a partir dos detectores de evento de origem (fonte) associados. Quer dizer, a etapa 124 também compreende a derivação de uma ordem correta dos eventos de entrada pela combinação de uma informação de atraso a partir dos eventos que chegam ao longo do percurso de desvio ou redirecionado com uma informação de atraso a partir de eventos que chegam ao segundo nó ao longo do percurso direto.
[00070] Conforme será evidente para a pessoa versada, as etapas 122 e 124 em conjunto constituem o método 120, o qual pode ser realizado no segundo nó de rede do sistema de computação distribuído. De modo a se ser capaz de executar as respectivas etapas dos métodos 100, 110 e 120, o sistema de computação distribuído e/ou o primeiro nó de rede e/ou o segundo nó de rede podem compreender respectivos meios para as etapas individuais, respectivamente. Desse modo, esse meio, como, por exemplo, um meio para a transferência, um meio para o encaminhamento, um meio para recebimento ou um meio para processamento, pode compreender um circuito analógico ou digital elétrico, o que pode ser programado de modo conforme. Por exemplo, um sistema de computação distribuído pode compreender uma pluralidade de CPUs funcionando como nós de rede individuais. De forma correspondente, os primeiro e segundo nós de rede podem ser CPUs individuais separadas do sistema de computação distribuído. De acordo com algumas modalidades, o sistema de computação distribuído pode ser acoplado a uma rede de sensor (sem fio), em particular uma rede de posicionamento ou localização, o que foi descrito na porção introdutória. No caso de uma rede de sensor de localização, a última pode entregar dados de sensor brutos ou eventos brutos, compreendendo dados de posição, bem como dados cinemáticos, para o sistema de computação distribuído. Os dados brutos de sensor podem ser considerados como o nível mais baixo de dados de evento no sistema de computação distribuído. Também pode servir para a entrega do sinal de relógio clk. Com base nos dados brutos de sensor de nível mais baixo, os assim denominados eventos primitivos podem ser detectados como eventos de primeiro nível. Quer dizer, os eventos primitivos são apenas com base em dados brutos de sensor (localização). Todos os eventos de nível mais alto então são derivados a partir dos eventos primitivos, o que tem a vantagem de as taxas de dados extremamente altas dos dados brutos de sensor poderem ser evitadas dentro do sistema de computação distribuído. Isto pode permitir uma detecção de evento em tempo real e um processamento, tal como requerido pela detecção de evento para eventos esportivos altamente populares, tal como futebol, por exemplo. Quer dizer, em uma modalidade em particular, o sistema de computação distribuído pode ser usado para a detecção de eventos em um jogo esportivo, tal como futebol, rúgbi ou futebol americano.
[00071] As modalidades da presente invenção serão detalhadas adicionalmente agora, com referência às figuras 2 a 5.
[00072] Considere uma topologia de rede de um sistema de computação distribuído 200 descrito na figura 2a. O sistema de computação distribuído 200 de exemplo compreende roteadores 210 e 220. Cada roteador 210, 220 tem associado a ele uma pluralidade de nós de rede do sistema de computação distribuído 200. Por exemplo, o roteador 210 tem associado a ele um primeiro nó de rede N1 e um segundo nó de rede N2. O segundo roteador 220 tem associado a ele um terceiro nó de rede N3, bem como um quarto nó de rede N4 do sistema de computação distribuído 200. Os roteadores 210 e 220 são interconec- tados através do enlace 230 (por exemplo, um enlace de Ethernet), de modo que todos os nós de rede N1 a N4 sejam interconectados a cada outro.
[00073] A figura 2a ilustra, em forma de exemplo, uma situação de rede antes de uma migração de detector de evento do nó N1 para o nó N2. Antes de sua migração, um detector de evento de exemplo roda no nó N1 e assina três eventos de entrada A (publicados ou emitidos pelo nó N3), B (publicado pelo nó N2) e C (publicado pelo nó N4). O detector de evento a ser migrado a partir do nó N1 a N2 gera, com base nos eventos de entrada assinados A, B e C, o evento compósito D, o que de novo é submetido pelo nó de rede N3. Em outras palavras, o evento de entrada A é provido para o detector de evento rondando no primeiro N1 de rede pelo detector de evento de origem ou de fonte rodando no nó N3 (veja o número de referência 242). O segundo evento de entrada B é provido para o detector de evento do nó N1 pelo segundo nó de rede N2 (veja o número de referência 244). O terceiro evento de entrada C é provido para o detector de evento rodando no nó de rede N1 pelo nó de rede N4 (veja o número de referência 246). O detector de evento rodando no primeiro nó de rede N1 é um detector de evento de origem ou de fonte para o evento compósito D, o qual inicialmente é provido a partir do nó de rede N1 para um detector de evento de nível mais alto rodando no nó de rede N3 (veja o número de referência 248).
[00074] Voltando-nos, agora, para a figura 2b, é ilustrado um cenário após o detector de evento para o evento compósito D ter sido migrado ou transferido a partir do primeiro nó de rede N1 para o segundo nó de rede N2 ao se fazer uso do método 100. Quando este detector de evento é migrado de N1 para N2, os nós de fonte dos eventos de entrada assinados A, B e C permanecem os mesmos (isto é, N3, N2, N4), mas seus atrasos de evento associados mais definitivamente mudam. Como um exemplo, um atraso δ(B) de evento de entrada B no novo nó N2 pode se retrair devido a uma migração, porque o evento de entrada B agora é um evento local no segundo nó de rede N2, após uma migração. Os atrasos dos outros eventos de entrada assinados A e C podem ou não se retrair. Note que o atraso do evento compósito D no nó de rede N3 também pode mudar, embora o assinante no nó N3 não participe na migração.
[00075] A menos que os atrasos de evento δ(.) se retraiam para todos os eventos envolvidos, uma migração tímida tem probabilidade de falhar, porque o detector de evento migrado no nó N2 ou quaisquer de- tectores de evento em uma camada mais alta não mais vê os eventos assinados A, B e C em uma ordem correta (temporal), porque o valor de K que funcionou bem no nó antigo (N1) pode ser pequeno demais para o novo nó (N2) e os novos atrasos de evento δ’(.), após uma migração.
[00076] As modalidades da presente invenção têm por objetivo garantir eventos de entrada ordenados para um detector de evento migrado pela medição e adaptação de atrasos de evento. Usualmente, pode não ser possível rodar ambos os detectores de evento antigo e novo em paralelo, se uma sobrecarga de CPU ou um estouro de buffer tiver disparado a migração. Mais ainda, um encaminhamento do fluxo de dados completo a partir do nó antigo para o novo nó é proibitivo, já que pode causar cargas de rede e tempos de processamento altos por um longo tempo, se eventos em particular ocorrerem de forma esparsa.
[00077] As modalidades da presente invenção podem migrar ou transferir detectores de evento em um tempo de rodada e inicializar os valores de K de acordo com os detectores de evento antigos no novo nó. A latência introduzida é desprezível, e ambas as instâncias de detector de evento antigo e novo, bem como os detectores de evento de nível superior podem ver eventos em ordem em qualquer tempo. O detector de evento antigo pode parar, tão logo seu conteúdo ou uma informação de estado ter sido copiado / transferido para o novo nó de rede, e os tempos de processamento de rede podem ser mantidos em um mínimo.
[00078] Uma ideia por trás de modalidades da presente invenção é que, para uma migração cooperativa ou uma transferência de ponto a ponto do detector de evento de um nó para um outro, o novo nó de rede não apenas assina eventos de entrada necessários de seus detectores de evento de origem ou de fonte, mas o novo nó também en- caminha aqueles eventos de entrada para o novo nó, da mesma forma. Desta forma, o novo nó de computação pode derivar a ordem temporal correta (ou o valor de K) pela combinação de uma informação de atraso de evento a partir dos eventos de entrada que chegam ao longo de dois percursos diferentes (um percurso de atraso via o nó antigo e um percurso direto a partir das fontes de evento de entrada).
[00079] A figura 3 descreve um quadro de sequência de mensagem (MSC) 300 a partir de um processo de migração de detector de evento de exemplo de acordo com uma modalidade.
[00080] Conforme pode ser visto a partir do quadro de sequência de mensagem 300, o nó de rede N2 pode assinar, primeiramente (veja o número de referência 302), para os eventos de entrada A, B e C do processo ou objeto de detector de evento ainda a ser executado no primeiro nó (antigo) (N1). Aqui, a assinatura 302 para os eventos de entrada A, B e C ocorre em um instante de tempo t0. A assinatura 302 pode ocorrer, por exemplo, em resposta a uma instrução de migração, a qual foi recebida a partir de um controlador de rede central no nó de rede N2. A referida entidade de controlador central pode ter uma informação sobre mais ou todos os atrasos de sinais de evento viajando ao longo de rotas diferentes no sistema distribuído. Desse modo, um atraso de evento pode ser, por exemplo, devido a uma instabilidade diferente, capacidades diferentes de processamento e/ou tempos de propagação de sinal diferentes dos percursos ou das rotas de rede diferentes. De forma alternativa ou adicional, o controlador central pode ter uma informação sobre mais ou todas as situações de carga (por exemplo, uma carga de CPU) de nós individuais e/ou uma informação indicativa de uma carga de sistema geral. Daí, de acordo com algumas modalidades, um aparelho para a migração pode ter um conhecimento de parâmetro de sistema geral. De acordo com ainda outras modalidades, o aparelho para a migração também pode ser não central, isto é, distribuído por uma pluralidade de nós de rede. Neste caso, um nó de rede pode ter apenas uma informação limitada indicativa de sua própria carga ou situação de atraso de evento. Daí, um conhecimento de parâmetro de sistema geral pode não estar disponível em algumas modalidades.
[00081] O MSC 300 também assume que uma instância de detector de evento já foi criada (instanciada) no novo nó de rede N2. Quer dizer, um aparelho para migração também pode compreender um meio para a criação de uma instância de processo ou objeto, o que corresponde ao primeiro detector de evento, no segundo nó de modo a se obter o segundo detector de evento. Uma instância é para ser entendida como uma ocorrência ou uma cópia de um objeto, independentemente de estar em execução ou não. As instâncias de uma classe ou um objeto compartilham o mesmo conjunto de atributos, ainda tipicamente diferirão no que aqueles atributos contêm.
[00082] Também, no instante de tempo t0, ou brevemente após o referido tempo t0, o segundo nó de rede N2 pode enviar uma mensagem de requisição de transferência de ponto a ponto para o primeiro nó de rede N1 (veja o número de referência 304). Em resposta à última mensagem de requisição de transferência de ponto a ponto, o nó de rede antigo N1 pode começar o encaminhamento da pluralidade de eventos de entrada A, B e C a partir do primeiro nó N1 para o segundo nó N2 (veja o número de referência 316). Ainda, o primeiro nó N1 pode responder à mensagem de requisição de transferência de ponto a ponto da etapa 304 com duas mensagens. Uma primeira mensagem transferida do nó antigo N1 para o novo nó N2 pode manter a informação de atraso atual para cada evento de entrada A, B e C assinado (veja a etapa 312). Quer dizer, uma informação sobre atrasos de evento individuais correspondendo à pluralidade de eventos de entrada A, B e C é transferida a partir do primeiro nó N1 para o segundo nó N2 na etapa 312. Por exemplo, o nó N1 pode receber os eventos de entrada com os atrasos de evento individuais δ(A) = 30 ms, δ(B) = 10 ms e δ(C) = 20 ms, de modo que K = max (δ(A), δ(B), δ(C)) = 30 ms. Desse modo, os atrasos δ(.) já podem incluir as respectivas margens de segurança. Daí, de acordo com algumas modalidades, os atrasos de evento individuais δ(A), δ(B), δ(C) e/ou o valor K resultante K = max (δ(A), δ(B), δ(C)) podem ser transferidos a partir do nó N1 para o nó N2 através da mensagem 312. O pacote ou a mensagem de informação de atraso 312 também pode manter a estampa de tempo atual ts, de modo que o segundo nó N2 possa determinar df = clk - ts, isto é, o suba- traso df de encaminhamento de um evento do nó N1 para o nó N2. Seja df 5 ms para o presente exemplo. Em outras palavras, uma transferência da informação de atraso de evento dos eventos de entrada A, B e C a partir do primeiro nó N1 para o segundo nó N2 pode compreender a transferência de uma estampa de tempo de transferência ts sendo indicativa de um instante de tempo no qual a referida informação foi enviada do primeiro nó N1 para o segundo nó N2. Também, uma transferência da informação detalhada e atraso de evento pode compreender a determinação, no segundo nó N2, de um atraso de transferência comum df do primeiro nó N1 para o segundo nó N2, em que o atraso de transferência comum df é indicativo de uma diferença de tempo entre a estampa de tempo de transferência e um tempo de recepção ou de chegada da informação nos atrasos de evento no segundo nó N2. Tendo a informação de atraso de mensagem 312 à mão, o segundo nó N2 pode processar a pluralidade de eventos de entrada recebidos A, B e C inicialmente com base na informação de atraso de evento transferida (δ(A), δ(B), δ(C) e/ou K) e no atraso de transferência comum.
[00083] A segunda mensagem ou pacote mencionado anteriormente, o qual pode ser transferido a partir do nó antigo N1 para o novo nó N2 na etapa 314 compreende um instantâneo (isto é, uma cópia do presente estado) do detector de evento. Em outras palavras, na etapa 314, um conteúdo do detector de evento pode ser transferido do primeiro nó N1 para uma instância de detector de evento do segundo nó N2 para a obtenção de um detector de evento migrado no segundo nó N2.
[00084] Por exemplo, os serviços de sistema operacional podem compreender funcionalidades de cópia ou de transferência, ao que um meio de transferência para transferência do conteúdo pode ter acesso. Quer dizer, um meio de transferência pode compreender um meio para acesso a funcionalidades de acesso de processo ou objeto de um sistema operacional rodando nos nós de computação ou alguma outra entidade de controle do sistema distribuído. O meio de transferência também pode ser operável para “congelar” o conteúdo do primeiro detector de evento em um instante de tempo pré-definido, de modo a se obter uma condição definida do primeiro detector de evento no instante de tempo de congelamento. Em outras palavras, uma transferência do conteúdo do detector de evento do primeiro nó N1 para o segundo nó N2 pode compreender o congelamento de um estado atual do detector de evento do primeiro nó N1 e a cópia do estado congelado para uma instância do detector de evento do segundo nó N2. Desse modo, um “congelamento” significa que o detector de evento é levado para um estado determinado e cessa de responder a suas entradas no instante de tempo de congelamento. Em outras palavras, o primeiro detector de evento pode ser parado no instante de tempo de congelamento, de modo a se copiar seu conteúdo ou sua condição de estado para o segundo detector de evento instanciado.
[00085] Uma transferência do conteúdo 314 pode compreender uma cópia do conteúdo / estado congelado do primeiro detector de evento para o segundo detector de evento, de modo a se obter o mesmo estado determinado ou uma condição definida no segundo de- tector de evento do nó N2.
[00086] Antes do detector de evento recém-instanciado, isto é, do segundo detector ser começado ou comutado para ligado no segundo nó N2, os eventos de entrada (idênticos) de ambos os detectores de evento podem ser armazenados em buffer, de modo que ambos os detectores de evento, os quais, devido à cópia, de modo ideal, já tiveram a mesma condição interna definida, também obtêm dados de entrada idênticos começando a partir do instante de tempo pré-definido, isto é, do instante de “congelamento”. Uma vez que os relógios podem variar entre ambos os nós, o nó N1 deve garantir que o segundo nó N2 possa armazenar em buffer todos os eventos, de modo que possa recuperar o estado correto se originando a partir do instantâneo transfe-rido. Por exemplo, se o nó N1 não tiver processado um evento de entrada desde o instante de tempo t0, seu estado atual poderá ser usado para o instantâneo e tsnap = t0. Caso contrário, tsnap pode ser regulado para a estampa de tempo de ocorrência do último evento de entrada processado de nó N1. Após o envio do instantâneo na etapa 314, o primeiro nó de rede N1 pode terminar o detector de evento, já que o novo nó N2 agora pode assumir e começar a rodar a cópia do detector de evento original, o que é indicado pelo número de referência 315. Após o fechamento do detector de evento no nó antigo N1 e o começo da instância do detector de evento no novo nó N2, o nó antigo N1 pode continuar a encaminhar os eventos de entrada A, B e C (veja o número de referência 316) para o novo nó N2, até o último ter acabado um pro-cedimento de adaptação de atraso de evento 320, o qual será descrito na sequência.
[00087] Por exemplo, no instante de tempo t0 = clk = 100, o segundo nó de rede (isto é, o novo) N2 envia a mensagem de requisição de transferência de ponto a ponto 304 para o nó de rede antigo N1. Como o nó de rede antigo N1 está continuamente processando os eventos de entrada A, B e C assinados, ele já pode estar ocupado com um evento de entrada tendo uma estampa de tempo 180. Quando a mensagem de requisição de transferência de ponto a ponto a partir do nó N2 chega, o nó de rede antigo N1 pode tirar o instantâneo do detector de evento original, regular tsnap para 180 (correspondente à estampa de tempo do último evento de entrada processado), enviar a mensagem de instantâneo 314 para o novo nó de rede N2 e terminar o detector de evento original no nó de rede N1. O novo nó de rede N2 pode regular o estado da nova instância de detector de evento e processar quaisquer eventos de entrada A, B e C armazenados em buffer com uma estampa de tempo acima de tsnap (isto é, 180) apenas. Quer dizer, o encaminhamento dos eventos de entrada A, B e C a partir do nó de rede antigo N1 para o novo nó de rede N2 compreende o armazenamento em buffer, no novo nó N2, de todos os eventos de entrada A, B e C encaminhados e/ou recebidos, começando no tempo t0 da mensagem de requisição de transferência de ponto a ponto 304, até o tempo de instantâneo tsnap. Quando o detector de evento migrado no novo nó N2 começa a rodar, ele pode processar o evento armazenado em buffer tendo uma estampa de tempo, isto é, um tempo de ocorrência, acima do tempo de instantâneo tsnap. Em outras palavras, o recebimento da pluralidade de eventos de entrada A, B e C encaminhados a partir do primeiro nó N1 pode compreender, no novo nó N2, o armazenamento em buffer de todos os eventos de entrada A, B e C encaminhados até o tempo de instantâneo tsnap, quando o conteúdo / estado congelado do detector de evento é transferido a partir do primeiro nó N1 para o segundo nó N2, e em que um processamento da pluralidade de eventos de entrada A, B e C recebidos no segundo nó N2 compreende o processamento de eventos armazenados em buffer tendo uma estampa de tempo de evento ou um tempo de ocorrência acima do tempo de instantâneo tsnap.
[00088] A seguir, a adaptação de uma informação de atraso de evento (δ(A), δ(B), δ(C) e K) da etapa 320 será descrita em maiores detalhes. Durante uma etapa 320, os atrasos de evento transferidos δ(A), δ(B), δ(C) do nó antigo N1 e/ou o valor de K resultante podem ser sucessivamente adaptados ou atualizados. Ainda, ecos de eventos de entrada assinados, os quais são recebidos no segundo nó N2 através do percurso de desvio a partir do nó antigo N1, são cancelados. Com modalidades, é possível mover corretamente um detector de evento rodando de um primeiro nó de rede N1 para um segundo nó de rede N2. Não obstante, no novo nó de rede N2, os atrasos de evento dos eventos de entrada A, B e C assinados e, portanto, os valores de K adequados podem ser diferentes, já que os atrasos dos eventos assinados podem ter mudado devido à migração e à recepção direta resultante. Ao invés de computar o tamanho de buffer K’D para o evento compósito D desde o esboço no segundo nó N2, o referido tamanho de buffer K’D pode ser inicializado de acordo com a informação de atraso de evento recebida a partir do nó antigo N1 por meio da mensagem de informação de atraso 312. Quer dizer, o atraso máximo ou tamanho de buffer K’D no novo nó pode ser determinado de acordo com: K’D = KD + df = max(δ(A) + df, δ(B) + df, δ(C) + df) = max(30+5, 10+5, 20+5) = 35 ms, em que KD denota o tamanho de buffer de evento compósito D no nó antigo N1.
[00089] Quer dizer, a etapa 124 de processamento da pluralidade de eventos de entrada A, B e C recebidos no segundo nó N2 pode compreender a determinação de um tempo de saída tout para retransmissão de um evento de entrada recebido para o detector de evento migrado com base em sua respectiva ocorrência de evento ou tempo de detecção e um atraso de evento máximo K’D da pluralidade de eventos de entrada A, B e C.
[00090] Conforme mostrado na figura 4, o novo nó de rede N2 recebe todos os eventos de entrada (A, B e C) duas vezes. Em geral, um evento de entrada e atinge o novo nó N2 em um percurso direto 402 com um atraso δ’(e) e também atinge o novo nó N2 em um percurso de desvio 404 através do nó de rede antigo N1. Desse modo, o percurso direto 402 atinge a partir de um nó de origem ou de fonte N3 através da rede distribuída 406 diretamente para o nó de destino N2, ao passo que o percurso de desvio atinge a partir do nó de fonte N3 através da rede 406 para o nó antigo N1 e a partir dali para o novo nó N2. Tão logo o novo nó N2 receba um evento de entrada e ao longo do percurso direto 402, ele pode atualizar seu tampão de buffer K pelo uso de δ’(e) ao invés de δ(e) + df. Isto é, a etapa de processamento 124 também compreende a atualização da informação sobre os atrasos de evento individuais com base em atrasos de evento individuais da pluralidade de eventos de entrada recebidos a partir dos eventos de entrada associados através do percurso direto 402. Isto é, a informação sobre um atraso de evento individual correspondente a um evento de entrada no primeiro nó pode ser atualizada, tão logo o referido evento de entrada seja recebido no segundo nó através de um percurso direto 402 a partir do detector de evento de fonte N3 associado ao evento de entrada e, de modo que o atraso de evento antigo correspondente δ(e) + df seja substituído por uma diferença entre a ocorrência de evento ou um tempo de detecção no detector de evento de origem N3 e um tempo de recepção ou de chegada de evento do respectivo evento e no segundo nó N2.
[00091] Por exemplo, um novo atraso (direto) de δ’(A) = 25 ms para o primeiro evento recebido diretamente A reduziria o tamanho de buffer requerido KD de 35 ms para max (25, 15, 25) = 25 ms. Um valor de K atualizado pode ser anunciado a partir do segundo nó N2 para detec- tores de evento de assinatura em níveis de hierarquia de evento mais altos ou superiores. Quer dizer, no caso de atualização da informação de atraso de evento transferida leva a um atraso de evento máximo atualizado ou um valor de buffer (valor de K) da pluralidade de eventos de entrada (por exemplo, A, B, C), o referido atraso de evento máximo atualizado ou valor de buffer pode ser comunicado para um fluxo normal ou detectores de evento de camada mais alta, os quais estão usando um evento de saída D do detector de evento migrado do segundo nó N2 como um evento de entrada. Em outras palavras, isto significa que o valor de K atualizado pode ser comunicado para detectores de evento de camada mais alta que assinaram o evento compósito D do detector de evento migrado.
[00092] Embora o recebimento dos eventos de entrada no novo nó duas vezes possa ser vantajoso para inicialização do novo tamanho de buffer K, os eventos de entrada ecoados imporiam problemas para um detector de evento migrado. Para garantir que uma unidade de ordenação de evento associada ao detector de evento migrado apenas veja um evento de entrada uma vez, um dos eventos ecoados precisa ser abandonado. Para cada tipo de evento A, B, C, haverá um primeiro tempo quando o novo nó N2 vir um evento através do percurso direto 402 e seu eco através do percurso de desvio 404. Antes daquele momento, o evento de entrada com o atraso mais baixo é passado ao longo da unidade de ordenação, enquanto a última versão recebida do evento de entrada é abandonada. Tão logo a versão de evento direto, isto é, a versão de evento e recebida através do percurso direto 402, é recebida, o nó antigo N1 pode ser notificado que este tipo de evento em particular não é para ser encaminhado mais a partir do nó antigo N1 para o novo nó N2. Quer dizer, o segundo nó N2 pode ser operável para informar ao primeiro nó N1 para parar o encaminhamento de um evento de entrada e, tão logo o segundo nó N2 tenha recebido o res- pectivo evento de entrada e através do percurso direto 402 a partir de um detector de evento de origem (por exemplo, N3) do sistema de computação distribuído 406. Um emissor de um evento pode ser determinado, por exemplo, através de uma informação de emissor compreendida por pacotes recebidos.
[00093] Voltando-nos, agora, para a figura 5, é ilustrado um pseudocódigo (abreviado) 500 da adaptação de atraso descrita e um cancelamento de eco, de acordo com uma modalidade da presente invenção.
[00094] O pseudocódigo 500 ilustrado começa com uma inicialização de um eco de objeto de tipo EventList (veja o número de referência 502). Então, em um laço for 504, os atrasos de evento d do detector de evento migrado são inicializados com os atrasos de evento transferidos do primeiro nó mais o valor de atraso de transferência comum df. Em uma etapa 506, o valor de K do detector de evento novo ou migrado EDnew é determinado de acordo com max(delays). A primeira declaração if 510 no laço enquanto 508 checa se um ID de um evento recebido pertence à quantidade de eventos assinados. Se este não for o caso, então, a recepção de eventos é continuada até um evento de entrada e assinado ser recebido. Se o evento de entrada e assinado tiver sido recebido pelo percurso direto 402 (veja o laço if 512), então, o atraso de evento do de evento e tendo o id é atualizado para o valor clk - e.ts (veja o número de referência 514). Subsequentemente, o valor de K é atualizado na linha 516. No caso em que o valor de K atualizado Kn não é igual ao valor de K anteriormente determinado, o valor de K do detector de evento novo ou migrado EDnew é atualizado para o novo valor de K Kn. Adicionalmente, o valor de K mudado é notificado para os detectores de evento de camada mais alta (veja a declaração if 518). Também, o nó antigo N1 é notificado que não é necessário continuar o encaminhamento do evento e tendo o identificador id (veja a linha 520). Na próxima declaração if 522, um eco de evento e é deletado ou apagado no caso em que está presente. Caso contrário, o eco é adicionado (veja o número de referência 524) e o evento e recebido é empurrado para a unidade de ordenação para a instância de detector de evento novo ou migrado EDnew.
[00095] O conceito de transferência de ponto a ponto ou migração cooperativa de acordo com as modalidades da presente invenção pode executar uma migração segura de detectores de evento a partir de um primeiro nó para um segundo nó de um sistema de computação distribuído e pode simultaneamente assegurar uma ordem de evento total para o novo detector de evento. Os detectores de evento podem ser copiados e imediatamente interrompidos, porque o detector de evento migrado interativamente calibra seus valores de K. As modalidades da presente invenção podem obter um processamento de evento confiável, distribuído de fluxos de sensor de taxa de dados alta, mesmo sob a predominância de eventos fora de ordem. Os atrasos de evento podem ser medidos e adaptados em tempo de rodada e eventos podem ser postergados, por tanto tempo quanto necessário para se garantir uma ordem total de fluxos de evento entrando. Nenhum conhecimento a priori de atrasos de evento é requerido. Para equilibrar a carga e melhorar o uso de uma potência de computação disponível, os detectores de evento podem migrar em tempo de rodada enquanto restrições de sincronismo ainda são mantidas válidas.
[00096] As modalidades da presente invenção funcionam bem em um sistema de localização em tempo real (RTLS) em uma aplicação de futebol. Um RTLS como esse pode rastrear 144 transmissores ao mesmo tempo em 2000 pontos de amostragem por segundo para uma bola e 200 pontos de amostragem por segundo para jogadores e juízes. Cada jogador pode ser equipado com quatro transmissores, um em cada um de seus membros. Os dados brutos de sensor a partir dos transmissores compreendem posições absolutas em milímetros, velocidade vetorial, aceleração e qualidade de localização (QoL) para qualquer direção. O futebol precisa destas taxas de amostragem. Com 2000 pontos de amostragem por segundo para a bola e uma velocidade de até 150 km/h, duas posições sucessivas podem estar separadas por 2 cm. Uma vez que os eventos de futebol como passe, passe em tabela, chute a gol, etc., ocorrem em uma fração de um segundo, um processamento de evento e uma migração devem assegurar que eventos sejam detectados a tempo, de modo que uma hierarquia de detectores de evento possa ajudar a um observador humano, por exemplo, um repórter, a trabalhar com a saída ao vivo do sistema.
[00097] A descrição e os desenhos meramente ilustram os princípios da invenção. Assim, será apreciado que aqueles versados na técnica serão capazes de divisarem vários arranjos que, embora não explicitamente descritos ou mostrados aqui, concretizam os princípios da invenção e são incluídos em seu espírito e escopo. Mais ainda, todos os exemplos recitados aqui são principalmente pretendidos expressamente para serem apenas para fins pedagógicos para ajudarem ao leitor no entendimento dos princípios da invenção e nos conceitos contribuídos pelo(s) inventor(es) para extensão da técnica, e são para serem construídos como sendo sem limitação para esses exemplos e condições especificamente recitados. Mais ainda, todas as declarações aqui recitando princípios, aspectos e modalidades da invenção, bem como exemplos específicos da mesma são pretendidas para envolverem os equivalentes da mesma.
[00098] Blocos funcionais denotados como “meios para...” (a execução de uma certa função) devem ser entendidos como blocos funcionais compreendendo um circuito que é adaptado para a execução de uma certa função, respectivamente. Um “meio para alguma coisa” pode ser entendido também como um “meio sendo adaptado ou operável para alguma coisa”. Um meio sendo adaptado para a execução de certas funções não implica, daí, que esse meio necessariamente está executando a referida função (em um dado instante de tempo).
[00099] As funções de vários elementos mostrados nas figuras, incluindo quaisquer blocos funcionais, podem ser providas através do uso de um hardware dedicado, por exemplo, um processador, bem como um hardware capaz de executar um software em associação com um software apropriado. Quando providas por um processador, as funções podem ser providas por um único processador dedicado, por um processador compartilhado único, ou por uma pluralidade de processadores individuais, alguns dos quais podendo ser compartilhados. Mais ainda, um uso explícito do termo “processador” ou “controlador” não deve ser construído para se referir exclusivamente a um hardware capaz de executar um software, e pode incluir de forma implícita, sem limitação, um hardware de processador de sinal digital (DSP), um processador de rede, um circuito integrado específico de aplicação (ASIC), um arranjo de porta programável de campo (FPGA), uma memória apenas de leitura (ROM) para armazenamento de software, uma memória de acesso randômico (RAM) e um armazenamento não volátil. Outro hardware, convencional e/ou personalizado, também pode ser incluído.
[000100] Deve ser apreciado por aqueles versados na técnica que quaisquer diagramas de blocos aqui representam vistas conceituais de um circuito ilustrativo concretizando os princípios da invenção. De modo similar, será apreciado que quaisquer fluxogramas, diagramas de fluxo, diagramas de transição de estado, pseudocódigo e similares representam vários processos os quais podem ser substancialmente representados em um meio que pode ser lido em computador e assim executados por um computador ou processador, independentemente de esse computador ou processador ser explicitamente mostrado.
[000101] Adicionalmente, é para ser notado que os métodos expostos no relatório descritivo podem ser implementados por um dispositivo tendo meios para a execução de cada uma das respectivas etapas destes métodos.
[000102] Ainda, é para ser entendido que a exposição de múltiplas etapas ou funções expostas no relatório descritivo não deve ser construída como estando na ordem específica. Portanto, a exposição de múltiplas etapas ou funções não limitará estas a uma ordem em particular, a menos que essas etapas ou funções não sejam intercambiá- veis por razões técnicas.
[000103] Mais ainda, em algumas modalidades, uma única etapa pode incluir ou pode ser dividida em múltiplas subetapas. Essas subetapas podem ser incluídas em parte da exposição desta única etapa, a menos que explicitamente excluídas.

Claims (14)

1. Método (100; 300) para migração de um detector de evento de um primeiro nó (N1) de um sistema de computação distribuído (200) para um segundo nó (N2) do sistema de computação distribuído, sendo que o detector de evento processa uma pluralidade de eventos de entrada (e; A, B, C) para a geração de pelo menos um evento de saída (D) com base nos eventos de entrada, sendo que cada um dos eventos de entrada tem associado a ele um atraso de evento individual correspondente a um tempo de propagação do evento de entrada para o primeiro nó (N1), o método (100; 300) compreendendo, a transferência (112; 312) a partir do primeiro nó (N1) para o segundo nó (N2) de uma informação sobre atrasos de evento correspondentes à pluralidade de eventos de entrada (e; A, B, C) no primeiro nó (N1); a transferência (114; 314) o conteúdo do detector de evento a partir do primeiro nó (N1) para o segundo nó (N2), para a obtenção de um detector de evento migrado no segundo nó; o encaminhamento (116; 316) da pluralidade de eventos de entrada (e; A, B, C) do primeiro nó (N1) para o segundo nó (N2); o recebimento (122) no segundo nó (N2) da pluralidade de eventos de entrada (e; A, B, C) encaminhados a partir do primeiro nó (N1) e, em paralelo, a partir dos detectores de evento de origem associados à pluralidade de eventos de entrada; e o processamento (124; 320) no segundo nó (N2) da pluralidade de eventos de entrada recebidos (e; A, B, C) com base na informação transferida nos eventos de entrada e com base nos atrasos de evento da pluralidade de eventos de entrada (e; A, B, C) recebidos a partir dos detectores de evento de origem associados, caracterizado pelo fato de que inclui ainda, o processamento (124; 320) da pluralidade de eventos de entrada recebidos (e; A, B, C) no segundo nó (N2) compreender a determinação de um tempo para retransmissão de um evento de entrada recebido para o detector de evento migrado com base em seu tempo de ocorrência de evento e um atraso de evento máximo (K) da pluralidade de eventos de entrada, sendo que o valor de atraso de evento máximo (K’D) é baseado na informação transferida sobre os atrasos de evento e baseado nos atrasos de evento de uma pluralidade de eventos de entrada recebidos (e; A, B, C) dos detectores de evento de origem associados.
2. Método (100; 300), de acordo com a reivindicação 1, ca-racterizado pelo fato de a transferência (112; 312) da informação sobre os atrasos de evento dos eventos de entrada do primeiro nó (N1) para o segundo nó (N2) compreender a transferência de uma estampa de tempo de transferência (ts) que é indicativa de um tempo no qual a referida informação foi enviada a partir do primeiro nó para o segundo nó.
3. Método (100; 300), de acordo com a reivindicação 2, ca-racterizado pelo fato de a transferência (112; 312) da informação sobre os atrasos de evento compreender a determinação, no segundo nó (N2), de um atraso de transferência comum (df) a partir do primeiro nó (N1) para o segundo nó (N2), em que o atraso de transferência comum (df) é indicativo de uma diferença de tempo entre a estampa de tempo de transferência (ts) e um tempo de recepção da informação sobre os atrasos de evento no segundo nó (N2).
4. Método (100; 300), de acordo com a reivindicação 3, ca-racterizado pelo fato de o processamento (124; 320) da pluralidade de eventos de entrada (e; A, B, C) no detector de evento migrado ser inicialmente com base na informação sobre atrasos de evento no primeiro nó (N1) e no atraso de transferência comum (df).
5. Método (100; 300), de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de a transferência (114; 314) do conteúdo do detector de evento do primeiro nó (N1) para o segundo nó (N2) compreender o congelamento de um estado atual do detector de evento do primeiro nó (N1) e a cópia do estado congelado para uma instância do detector de evento do segundo nó (N2).
6. Método (100; 300), de acordo com qualquer uma das rei-vindicações precedentes, caracterizado pelo fato de o recebimento (122) da pluralidade de eventos de entrada (e; A, B, C) encaminhados a partir do primeiro nó (N1) compreender, no novo nó (N2), o armazenamento em buffer de todos os eventos de entrada encaminhados (e; A, B, C), até um tempo de instantâneo (tsnap), quando o conteúdo do detector de evento for transferido do primeiro nó (N1) para o segundo nó (N2), e em que um processamento (124; 320) da pluralidade de eventos de entrada (e; A, B, C) no segundo nó (N2) compreende o processamento de eventos armazenados em buffer tendo um tempo de ocorrência de evento acima do tempo de instantâneo (tsnap).
7. Método (100; 300), de acordo com qualquer uma das rei-vindicações precedentes, caracterizado pelo fato de a informação sobre um atraso de evento correspondente a um evento de entrada (e; A, B, C) no primeiro nó (N1) ser atualizado tão logo o referido evento de entrada seja recebido no segundo nó (N2) através de um percurso direto (402) a partir do detector de evento de origem (N3) associado ao evento de entrada (e; A, B, C), de modo que o atraso de evento correspondente relacionado ao primeiro nó (N1) seja substituído por um atraso de evento relacionado ao percurso direto (402) do evento de entrada (e; A, B, C) para o segundo nó (N2).
8. Método (100; 300), de acordo com a reivindicação 7, ca-racterizado pelo fato de o processamento (124; 320) da pluralidade de eventos de entrada (e; A, B, C) no segundo nó (N2) compreender a atualização da informação transferida em um atraso de evento indivi dual, e, caso a referida atualização leve para um valor de atraso de evento máximo atualizado (K) da pluralidade de eventos de entrada (e; A, B, C), o referido valor de atraso de evento máximo atualizado (K) será comunicado para os detectores de evento tendo uma saída do detector de evento migrado do segundo nó (N2) como uma entrada.
9. Método (100; 300), de acordo com qualquer uma das rei-vindicações precedentes, caracterizado pelo fato de o segundo nó (N2) informa ao primeiro nó (N1) para parar o encaminhamento de um evento de entrada tão logo o segundo nó (N2) tenha recebido o respectivo evento de entrada através de um percurso direto (402) a partir de um detector de evento de origem do sistema de computação distribuído (200).
10. Método (100; 300), de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de um evento ser um evento primitivo, o qual é diretamente baseado nos dados de sensor, ou um evento compósito, o qual é baseado em eventos primitivos (e; A, B, C).
11. Método (100; 300), de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de os eventos de entrada (e; A, B, C) serem originalmente detectados em nós distribuídos do sistema de computação distribuído (200), e em que os eventos de entrada são baseados em fluxos de dados de sensor paralelos de um sistema de localização geográfica.
12. Método (120) para a migração de um detector de evento de um primeiro nó (N1) de um sistema de computação distribuído (200) para um segundo nó (N2) do sistema de computação distribuído, em que o detector de evento processa uma pluralidade de eventos de entrada (e; A, B, C) para a geração de pelo menos um evento de saída (D) com base nos eventos de entrada, em que cada um dos eventos de entrada tem associado a ele um atraso de evento individual corres- pondente a um tempo de propagação do evento de entrada para o primeiro nó (N1), o método (120) caracterizado pelo fato de compreender: o recebimento (122) no segundo nó (N2) da pluralidade de eventos de entrada (e; A, B, C) encaminhados a partir do primeiro nó (N1) e, em paralelo, a partir dos detectores de evento de origem associados à pluralidade de eventos de entrada; e o processamento (124; 320) no segundo nó (N2) da pluralidade de eventos de entrada recebidos (e; A, B, C) com base na informação transferida nos eventos de entrada e com base nos atrasos de evento da pluralidade de eventos de entrada (e; A, B, C) recebidos a partir dos detectores de evento de origem associados, caracterizado pelo fato de que inclui ainda, o processamento (124; 320) da pluralidade de eventos de entrada recebidos (e; A, B, C) no segundo nó (N2) compreender a determinação de um tempo para retransmissão de um evento de entrada recebido para o detector de evento migrado com base em seu tempo de ocorrência de evento e um atraso de evento máximo (K) da pluralidade de eventos de entrada, sendo que o valor de atraso de evento máximo (K’D) é baseado na informação transferida sobre os atrasos de evento e baseado nos atrasos de evento de uma pluralidade de eventos de entrada recebidos (e; A, B, C) dos detectores de evento de origem associados.
13. Aparelho para a migração de um detector de evento de um primeiro nó (N1) de um sistema de computação distribuído (200) para um segundo nó (N2) do sistema de computação distribuído, em que o detector de evento processa uma pluralidade de eventos de entrada (e; A, B, C) para a geração de pelo menos um evento de saída (D) com base nos eventos de entrada, em que cada um dos eventos de entrada tem associado a ele um atraso de evento individual corres- pondente a um tempo de propagação do evento de entrada para o primeiro nó (N1), compreendendo, meio para o recebimento, no segundo nó (N2), da pluralidade de eventos de entrada (e; A, B, C) encaminhada a partir do primeiro nó (N1), e, em paralelo, a partir dos detectores de evento de origem associados à pluralidade de eventos de entrada; e meio para processamento, no segundo nó (N2), da pluralidade de eventos de entrada recebidos (e; A, B, C) com base na informação transferida sobre atrasos de evento e com base nos atrasos de evento da pluralidade de eventos de entrada (e; A, B, C) recebidos a partir dos detectores de evento de origem associados, caracterizado pelo fato de que inclui ainda, o meio de processamento é configurado para determinar um tempo para retransmissão de um evento de entrada recebido para o detector de evento migrado com base em seu tempo de ocorrência de evento e um atraso de evento máximo (K’D) da pluralidade de eventos de entrada, sendo que o valor de atraso de evento máximo (K’D) é baseado na informação transferida sobre os atrasos de evento e baseado nos atrasos de evento de uma pluralidade de eventos de entrada recebidos (e; A, B, C) dos detectores de evento de origem associados.
14. Sistema de computação distribuído (200) para a migração de um detector de evento de um primeiro nó (N1) de um sistema de computação distribuído (200) para um segundo nó (N2) do sistema de computação distribuído, em que o detector de evento processa uma pluralidade de eventos de entrada (e; A, B, C) para a geração de pelo menos um evento de saída (D) com base nos eventos de entrada, em que cada um dos eventos de entrada tem associado a ele um atraso de evento individual correspondente a um tempo de propagação do evento de entrada para o primeiro nó (N1), o sistema de computação distribuído (200) compreendendo, meio para a transferência, a partir do primeiro nó (N1) para o segundo nó (N2), de uma informação sobre atrasos de evento correspondentes à pluralidade de eventos de entrada (e; A, B, C) no primeiro nó (N1); meio para a transferência do conteúdo do detector de evento a partir do primeiro nó (N1) para o segundo nó (N2) para a obtenção de um detector de evento migrado no segundo nó; meio para encaminhamento da pluralidade de eventos de entrada (e; A, B, C) a partir do primeiro nó (N1) para o segundo nó (N2); meio para o recebimento, no segundo nó (N2), da pluralidade de eventos de entrada (e; A, B, C) encaminhada a partir do primeiro nó (N1), e, em paralelo, a partir dos detectores de evento de origem associados à pluralidade de eventos de entrada; e meio para processamento, no segundo nó (N2), da pluralidade de eventos de entrada recebidos (e; A, B, C) com base na informação transferida sobre atrasos de evento e com base nos atrasos de evento da pluralidade de eventos de entrada (e; A, B, C) recebidos a partir dos detectores de evento de origem associados, caracterizado pelo fato de que inclui ainda, o meio de processamento é configurado para determinar um tempo para retransmissão de um evento de entrada recebido para o detector de evento migrado com base em seu tempo de ocorrência de evento e um atraso de evento máximo (K’D) da pluralidade de eventos de entrada, sendo que o valor de atraso de evento máximo (K’D) é baseado na informação transferida sobre os atrasos de evento e baseado nos atrasos de evento de uma pluralidade de eventos de entrada recebidos (e; A, B, C) dos detectores de evento de origem associados.
BR112014010348-8A 2011-10-31 2012-03-14 Método e aparelho para migração de um detector de evento e sistema de computação distribuído para a migração de um detector de evento. BR112014010348B1 (pt)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EPPCT/EP/069159 2011-10-31
PCT/EP2011/069159 WO2013064171A1 (en) 2011-10-31 2011-10-31 Apparatus and method for transferring event detector processes
PCT/EP2012/054475 WO2013064273A1 (en) 2011-10-31 2012-03-14 Apparatus, method and computer program for migrating an event detector process

Publications (2)

Publication Number Publication Date
BR112014010348A2 BR112014010348A2 (pt) 2017-04-18
BR112014010348B1 true BR112014010348B1 (pt) 2021-08-03

Family

ID=45815572

Family Applications (2)

Application Number Title Priority Date Filing Date
BR112014010370-4A BR112014010370B1 (pt) 2011-10-31 2011-10-31 Aparelho e método para transferir processos detectores de evento
BR112014010348-8A BR112014010348B1 (pt) 2011-10-31 2012-03-14 Método e aparelho para migração de um detector de evento e sistema de computação distribuído para a migração de um detector de evento.

Family Applications Before (1)

Application Number Title Priority Date Filing Date
BR112014010370-4A BR112014010370B1 (pt) 2011-10-31 2011-10-31 Aparelho e método para transferir processos detectores de evento

Country Status (8)

Country Link
US (2) US9954932B2 (pt)
EP (2) EP2774035B1 (pt)
JP (2) JP5847953B2 (pt)
CN (2) CN104025051B (pt)
AU (2) AU2011380288B2 (pt)
BR (2) BR112014010370B1 (pt)
ES (2) ES2601804T3 (pt)
WO (2) WO2013064171A1 (pt)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2763041A1 (en) * 2013-01-31 2014-08-06 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Apparatus, method and computer program for processing out-of-order events
CH709742A1 (de) * 2014-06-05 2015-12-15 Swisstradingbox Ag Börsenhandelssystem.
US9891966B2 (en) 2015-02-10 2018-02-13 Red Hat, Inc. Idempotent mode of executing commands triggered by complex event processing
US10423468B2 (en) 2015-02-10 2019-09-24 Red Hat, Inc. Complex event processing using pseudo-clock
US10151215B2 (en) * 2015-06-01 2018-12-11 Solar Turbines Incorporated High speed recorder for a gas turbine engine
CN105105755B (zh) * 2015-06-25 2017-10-31 简极科技有限公司 一种智能球场系统及其数据获取方法
CN105786618B (zh) * 2016-02-24 2019-06-18 华为技术有限公司 加速器网络中路由报文的方法和装置
US11537419B2 (en) * 2016-12-30 2022-12-27 Intel Corporation Virtual machine migration while maintaining live network links
DE112018007416T5 (de) * 2018-03-30 2021-01-07 Sumitomo Electric Industries, Ltd. System, Servercomputer dafür, Steuerverfahren und Computerprogramm
US11143055B2 (en) 2019-07-12 2021-10-12 Solar Turbines Incorporated Method of monitoring a gas turbine engine to detect overspeed events and record related data
US11411969B2 (en) * 2019-11-25 2022-08-09 Red Hat, Inc. Live process migration in conjunction with electronic security attacks
US11354207B2 (en) 2020-03-18 2022-06-07 Red Hat, Inc. Live process migration in response to real-time performance-based metrics
JP2022019145A (ja) * 2020-07-17 2022-01-27 富士通株式会社 イベントストリーム処理方法及びイベントストリーム処理プログラム

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3231563B2 (ja) 1994-11-10 2001-11-26 日本電気株式会社 メッセージ到着順序制御方式
JPH09244984A (ja) * 1996-03-08 1997-09-19 Nippon Telegr & Teleph Corp <Ntt> イベント順序補正方法
US6052363A (en) * 1997-09-30 2000-04-18 Northern Telecom Limited Method for causal ordering in a distributed network
MXPA05000124A (es) 2003-01-08 2005-04-08 Nokia Corp Aparato y metodo asociado para el desempeno de operaciones de temporizacion en zonas por paquetes en un nodo movil operable en un sistema de comunicaciones de radio por paquetes.
US7010538B1 (en) * 2003-03-15 2006-03-07 Damian Black Method for distributed RDSMS
US7487206B2 (en) * 2005-07-15 2009-02-03 International Business Machines Corporation Method for providing load diffusion in data stream correlations
US9009234B2 (en) * 2007-02-06 2015-04-14 Software Ag Complex event processing system having multiple redundant event processing engines
CN100476742C (zh) 2007-02-09 2009-04-08 华中科技大学 基于对象存储设备的负载平衡方法
CN101441528B (zh) * 2007-11-19 2011-03-02 华硕电脑股份有限公司 计算机系统的输入装置与其操作方法
US8479216B2 (en) * 2009-08-18 2013-07-02 International Business Machines Corporation Method for decentralized load distribution in an event-driven system using localized migration between physically connected nodes and load exchange protocol preventing simultaneous migration of plurality of tasks to or from a same node
US8370560B2 (en) * 2009-11-16 2013-02-05 International Business Machines Corporation Symmetric live migration of virtual machines
JP5504872B2 (ja) * 2009-12-16 2014-05-28 日本電気株式会社 データストリーム処理システム及び方法、処理ノード再配置装置及びプログラム
WO2011127060A1 (en) * 2010-04-05 2011-10-13 Huawei Technologies Co., Ltd. Method for dynamic on demand startup of a process or resource
CN102223597A (zh) * 2010-04-15 2011-10-19 上海启电信息科技有限公司 一种移动定位装置
US8521974B2 (en) * 2010-11-23 2013-08-27 International Business Machines Corporation Migration of data in a distributed environment
US8478743B2 (en) * 2010-12-23 2013-07-02 Microsoft Corporation Asynchronous transfer of state information between continuous query plans

Also Published As

Publication number Publication date
EP2774035A1 (en) 2014-09-10
CN104025051B (zh) 2017-05-03
EP2774036A1 (en) 2014-09-10
CN103907092A (zh) 2014-07-02
JP5847956B2 (ja) 2016-01-27
BR112014010348A2 (pt) 2017-04-18
JP2015501031A (ja) 2015-01-08
AU2011380288B2 (en) 2015-09-17
US9954932B2 (en) 2018-04-24
AU2012331452B2 (en) 2015-06-18
CN103907092B (zh) 2017-03-08
JP5847953B2 (ja) 2016-01-27
US20140297800A1 (en) 2014-10-02
AU2011380288A1 (en) 2014-04-17
JP2015501493A (ja) 2015-01-15
CN104025051A (zh) 2014-09-03
ES2555578T3 (es) 2016-01-05
US9537937B2 (en) 2017-01-03
WO2013064171A1 (en) 2013-05-10
AU2012331452A1 (en) 2014-04-10
BR112014010370B1 (pt) 2021-08-10
ES2601804T3 (es) 2017-02-16
US20140280448A1 (en) 2014-09-18
WO2013064273A1 (en) 2013-05-10
EP2774035B1 (en) 2016-08-03
BR112014010370A2 (pt) 2017-04-25
EP2774036B1 (en) 2015-09-16

Similar Documents

Publication Publication Date Title
BR112014010348B1 (pt) Método e aparelho para migração de um detector de evento e sistema de computação distribuído para a migração de um detector de evento.
AU2014211579B2 (en) Apparatus, method and computer program for processing out-of-order events
US9641601B2 (en) Apparatus and method for synchronizing events
Yaseen et al. Synchronized network snapshots
Mutschler et al. Distributed low-latency out-of-order event processing for high data rate sensor streams
Mutschler et al. Adaptive speculative processing of out-of-order event streams
Liu et al. SAND: A fault-tolerant streaming architecture for network traffic analytics
Mutschler et al. Runtime migration of stateful event detectors with low-latency ordering constraints
CN116911398A (zh) 用于度量采集的机器学习
Mutschler Latency minimization of order-preserving distributed event-based systems
Mutschler et al. Dynamic Low-Latency Distributed Event Processing of Sensor Data Streams

Legal Events

Date Code Title Description
B06F Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]
B06U Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]
B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 14/03/2012, OBSERVADAS AS CONDICOES LEGAIS.