BRPI0721658A2 - migraÇço de fluxo de protocolo em tempo real - Google Patents
migraÇço de fluxo de protocolo em tempo real Download PDFInfo
- Publication number
- BRPI0721658A2 BRPI0721658A2 BRPI0721658-0A BRPI0721658A BRPI0721658A2 BR PI0721658 A2 BRPI0721658 A2 BR PI0721658A2 BR PI0721658 A BRPI0721658 A BR PI0721658A BR PI0721658 A2 BRPI0721658 A2 BR PI0721658A2
- Authority
- BR
- Brazil
- Prior art keywords
- server
- backup
- primary
- rtsp
- servers
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1034—Reaction to server failures by a load balancer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
MIGRAÇçO DE FLUXO DE PROTOCOLO EM TEMPO REAL. A presente invenção refere-se a um método para monitorar e migrar um servidor primário (131a-c) que transmite um fluxo de protocolo de fluxo contínuo em tempo real (RTSP). Os servidores de backup (21 la-o) monitoram pelo menos um servidor primário (131a-c) para determinar se o servidor primário (131a-c) está ativo. Mediante a determina- ção de que um servidor primário (131a-c) está ativo, os servidores de backup (21 la-c) as sumir o controle de uma conexão na qual o servidor primário inativo (21 la-o) era os dados de fluxo contínuo e, então, assumir o controle de uma transmissão do fluxo RTSP. O servi- dor de backup (211a-c) pode derivar adicionalmente a posição em um arquivo do próximo dado a ser transmitido necessário.
Description
"MIGRAÇÃO DE FLUXO DE PROTOCOLO EM TEMPO REAL" CAMPO DA TÉCNICA
Os presentes princípios, em geral, se referem a comunicações de fluxo de dados e, mais particularmente, a um sistema e método para proporcionar capacidades de recupera- ção após falha de comunicações de fluxo em tempo real.
ANTECEDENTES DA INVENÇÃO
Diversos sites da web de meio rico vêm proporcionando progressivamente grandes quantidades de dados de áudio e vídeo através da Internet para consumidores. Como um resultado, os dados de fluxo contínuo estão sendo transmitidos através da Internet em quan- tidades progressivamente maiores.
Entretanto, a natureza do fluxo contínuo de áudio e vídeo requer uma conexão constante com um servidor de fluxo contínuo para reprodução de áudio/vídeo. Um protocolo de fluxo contínuo em tempo real (RTSP)1 conforme descrito em Internet Working Group Do- cument RFC 3550, julho de 2003, geralmente dita que os dados sejam transferidos em pa- cotes distintos, que devem ser distribuídos para um cliente em ordem relativamente seqüen- cial. Adicionalmente, se um servidor de fluxo contínuo encontrar uma falha que evita que o servidor transmita adicionalmente os dados de fluxo, a experiência de cliente irá sofrer de- gradação, falha ou falha de exibição completa.
Diversos métodos para fixar as conexões baseadas em servidores de fluxo contí- nuo de falha foram propostos. Por exemplo, a recuperação após falha refinada que usa a migração de conexão descreve um método para proporcionar capacidades de recuperação após falha TCP ao rotear cada conexão de fluxo contínuo através de um endereço de proto- colo de Internet proxy. (Fine-grained failover using connection migration. Alex C. Snoeren, David G. Andersen, e Hari Balakrishnan, Proceedings of the 3rd USENIX Symposium on internet Technologies and Systems, páginas 221 a 232. USENIX, 2001). Este método pro- põe que, se um servidor de dados falhar, o servidor secundário pode assumir o papel do primário. Entretanto, esta transferência é agnóstica do protocolo de nível de aplicativo, e a sincronização de estado freqüente pode ser necessária, dependendo do aplicativo.
Uma implementação atual da migração de fluxo pode ser observada no servidor Helix™ da ReaNetwork™. A migração de fluxo Helix™ inclui fazer com que um aplicativo tocador de mídia de cliente se conecte a um servidor de backup se o servidor inicial falhar. O Helix™ tem alguns mecanismos básicos de recuperação após falha implementados. Estes mecanismos de recuperação após falha, entretanto, não atende o problema de um servidor para de funcionar durante o fluxo contínuo ao vivo. O modo em que isto funciona consiste em fornecer ao cliente uma lista de servidores de backup e, no caso em que um servidor para de funcionar o próprio cliente deve solicitar uma nova conexão a partir de um servidor de backup. Portanto, se o servidor primário parar de funcionar, é responsabilidade do clien- te, fazer alguma coisa com a informação. Entretanto, a qualidade da experiência de usuário é afetada à medida que o usuário pode perceber que o servidor parou de funcionar, e pode levar algum tempo inaceitável antes que o novo fluxo seja configurado devido às latências e armazenamento temporário de informações recebidas através de uma rede de comunica- ção, tal como, a Internet.
SUMÁRIO DA INVENÇÃO
Os presentes princípios propõem um sistema e método para monitorar e migrar as transmissões RTSP de maneira transparente em relação ao cliente, independente do clien- te, e que permite que a recuperação após falha ocorra sem ter que implementar o manuseio de recuperação após falha no cliente.
De acordo com um aspecto, os presentes princípios de monitoramento de protocolo de fluxo contínuo em tempo real (RTSP) e manuseio de recuperação após falha são obtidos por um sistema e método para monitorar e migrar para um servidor de backup um fluxo RTSP que transmite pacotes de protocolo em tempo real (RTP) que compreendem a abertu- ra de uma sessão de fluxo contínuo e o início de um fluxo de transferência de dados a partir de um servidor primário para um cliente, executar o ping no servidor primário através de pelo menos um servidor de backup, e que determina se o servidor primário se encontra ati- vo/inativo. Mediante a determinação de que servidor primário se encontra inativo, o método pode compreender adicionalmente assumir o controle do endereço de protocolo de Internet (IP) do servidor primário através de um servidor de backup, executar o Ioop através das sessões de fluxo contínuo abertas do servidor primário, que migra as conexões de protocolo de controle de transmissão (TCP) a partir do servidor primário para o servidor de backup, que deriva um estado de fluxo de sessão RTP para cada sessão de fluxo contínuo aberta, e resumindo o fluxo contínuo de sessão RTSP a partir do servidor de backup para o cliente que usa o estado de fluxo de sessão RTSP derivado. Mediante a determinação de que o servidor primário se encontra ativo, o método pode compreender adicionalmente as etapas de aguardar um tempo predeterminado; e retornar à dita etapa de executar o ping no servi- dor primário através de pelo menos um servidor de backup.
As vantagens, naturezas e diversos recursos adicionais dos presentes princípios aparecerão mais complemente mediante a consideração das implementações ilustrativas a serem descritos em detalhes em conexão com os desenhos em anexo.
BREVE DESCRIÇÃO DOS DESENHOS
Nos desenhos, as referências numéricas similares denotam os componentes simila- res em todas as vistas:
A Figura 1 é um diagrama de um sistema de rede de fluxo contínuo em tempo real,
como conhecido na técnica anterior.
A Figura 2 é um diagrama de um sistema de rede de fluxo contínuo em tempo real de acordo com os presentes princípios.
A Figura 3 é um diagrama em bloco de um método para a migração de um fluxo em tempo real para um servidor de backup mediante a falha do servidor primário, de acordo com os presentes princípios.
Deve-se entender que os desenhos servem para os propósitos de ilustrar os con-
ceitos dos presentes princípios e não são necessariamente a única configuração possível para ilustrar os presentes princípios.
DESCRIÇÃO DETALHADA
Sabe-se que os versados na técnica de comunicações de Internet transmitem ar- quivos de áudio e vídeo de fluxo contínuo através de um protocolo de fluxo contínuo em tempo real (RTSP). Geralmente, um protocolo RTSP requer a transmissão de alguma parte de um arquivo de mídia ao vivo a partir de um servidor no início de uma sessão de fluxo contínuo (com o armazenamento temporário de alguns dados a partir do servidor), e conti- nua a transmitir os dados restantes enquanto os dados de fluxo contínuo são exibidos ou, de outro modo, usados. Esta estrutura de transmissão permite que os dados de fluxo contínuo sejam exibidos à medida que são recebidos no cliente, em uma arquitetura de exibição no momento certo (just-in-time). Entretanto, uma vez que os dados de fluxo contínuo são envi- ados no momento certo, isto é, são requeridos ou usados logo após serem recebidos, retar- do de rede, ou uma falha no servidor pode afetar seriamente a qualidade da experiência do usuário.
Consequentemente, os presentes princípios proporcionam um sistema e método para monitorar fluxos de dados de áudio e vídeo transmitidos através de um protocolo de fluxo contínuo em tempo real, e migrar os fluxos diretamente a partir de servidores com falha ou sobrecarregados para um servidor de backup. Deve-se entender que os presentes princípios são descritos em termos de migra-
ção de fluxo RTSP em uma rede de comunicações digital; entretanto, os presentes princí- pios são muito mais amplos e podem incluir qualquer forma de transmissão de dados em qualquer rede de comunicações. Além disso, os presentes princípios são aplicáveis em qualquer sistema de transmissão de dados usado por computador, telefone, decodificador de sinais, enlace de satélite, etc. Os presentes princípios são descritos em termos de um sistema de transmissão de dados em tempo real; entretanto, os conceitos dos presentes princípios podem ser estendidos aos sistemas de transmissão de dados.
Deve-se entender que os elementos mostrados nas Figuras podem ser implemen- tados em diversas formas de hardware, software ou combinações destes. De preferência, estes elementos são implementados em uma combinação de hard-
ware e software em um ou mais dispositivos de propósito geral adequadamente programa- dos, que podem incluir um processador, memória e interfaces de entrada/saída. A presente descrição ilustra os presentes princípios. Deste modo, será avaliado que aqueles versados na técnica serão capazes de criar disposições que, embora não explicita- mente descritas ou mostradas no presente documento, incorporam os presentes princípios e são incluídas no espírito e escopo.
Todos os exemplos e linguagens condicionais recitadas no presente documento
são projetados para propósitos pedagógicos que auxiliam o leitor no entendimento dos pre- sentes princípios e conceitos contribuídos pelo inventor para promover a técnica, e devem ser construídos sem limitação a tais exemplos e condições especificamente citados.
Além disso, todas as declarações do presente documento que citam os princípios, aspectos e implementações dos presentes princípios, assim como os exemplos específicos destes, são projetados para englobar tanto equivalentes estruturais como funcionais dos mesmos.
Adicionalmente, pretende-se que tais equivalentes incluam tanto os equivalentes atualmente conhecidos, assim como os equivalentes desenvolvidos no futuro, isto é, quais- quer elementos desenvolvidos que realizem a mesma função, independente da estrutura.
Deste modo, por exemplo, será avaliado por aqueles versados na técnica que os diagramas em bloco apresentados no presente documento representam as vistas conceitu- ais de módulos ilustrativos que incorporam os presentes princípios. De maneira similar, será avaliado que quaisquer fluxogramas, diagramas de fluxo, diagramas de transição de estado, pseudocódigo, e similares, representam diversos processos que podem ser substancialmen- te representados em meio legível por computador e, então, executados por um computador ou processador, se tal computador ou processador é explicitamente mostrado ou não.
As funções dos diversos elementos mostrados nas Figuras podem ser proporciona- das através do uso de hardware dedicado, assim como hardware capaz de executar o soft- ware em associação com o software adequado. Quando proporcionado por um processador ou elemento, as funções podem ser proporcionadas por um único processador dedicado, por um único processador compartilhado, ou por uma pluralidade de processadores indivi- duais, alguns dos quais podem ser compartilhados. Além disso, o uso explícito do termo "processador" ou "controlador" não deve ser construído para se referir exclusivamente ao hardware capaz de executar software, e pode incluir implicitamente, sem limitação, o hard- ware de processador de sinal digital ("DSP"), memória somente leitura ("ROM") para arma- zenar software, memória de acesso aleatório ("RAM") e armazenamento não volátil.
Outro hardware, convencional e/ou personalizado, também pode ser incluído. De maneira similar, quaisquer redes, comutadores, roteadores ou blocos de decisão mostrados nas Figuras são apenas conceituais. Sua função pode ser realizada através da operação de lógica de programa, através da lógica dedicada, através da interação de controle de pro- grama e lógica dedicada ou, ainda, manualmente, sendo que a técnica particular é selecio- nável pelo implementador, conforme mais especificamente entendido a partir do contexto.
Nas reivindicações, qualquer elemento expresso como um meio para realizar uma função especificada, é projetado para englobar qualquer meio para realizar esta função in- cluindo, por exemplo, a) uma combinação de elementos de circuito que realiza esta função ou b) software, sob qualquer forma, que inclui, portanto, firmware, microcódigo, ou similares, combinados com o conjunto de circuitos adequado para executar este software para realizar a função. Os presentes princípios, conforme definidos por tais reivindicações consistem no fato de que as funcionalidades proporcionadas pelos diversos meios citados são combina- das e reunidas na maneira que as reivindicações requerem. Deste modo, considera-se quaisquer meios que possam proporcionar estas funcionalidades são equivalentes àqueles mostrados no presente documento.
Os presentes princípios envolvem a manutenção da informação sobre todas as sessões RTSP ativas e os servidores que estão servindo as mesmas em um local acessível para um servidor de backup. Os presentes princípios também contemplam a derivação da informação para recriar a conversação RTSP para cada sessão, junto com o estado de pro- tocolo de controle de transmissão (TCP) necessário para migrar cada conexão TCP. Um mecanismo pulsação é usado para manter o rastreamento de servidores que estão ativos em um pool de servidor. Quando existe um servidor de parada, a falha pode ser detectada e uma aquisição de endereço IP (substituição) é realizada. Usando os meios padrões, a cone- xão TCP, então, pode ser migrada para o servidor de backup. Estas etapas levam tipica- mente poucos milissegundos para serem concluídas. O servidor de backup, então, pode assumir o controle para o servidor original e enviar dados RTSP e protocolo em tempo real (RTP), como uma substituição para o servidor primário. Em algumas implementações úteis, os mesmos arquivos de mídia transmitidos pelos servidores primários estarão disponíveis para os servidores de backup. Isto pode ser obtido ao implementar um armazenamento cen- tralizado e exportar este sistema de arquivo usando, por exemplo, um Sistema de Arquivo de Rede (NFS) ou outro tipo de sistema ou método para efetuar o backup de arquivos em servidores de backup em rede.
Uma vez que o estado RTSP pode ser determinado ao monitorar o servidor, o prin- cipal problema consiste em como derivar o estado RTP entre um servidor e um cliente. Uma opção consiste em registrar os pacotes RTP que foram trocados entre um servidor e o clien- te. Entretanto, isto significa atualizar o estado diversas vezes, o que resulta em diversas transações de milhão por segundo.
As implementações dos presentes princípios da invenção podem explorar a sincro- nização de tempo implícita para evitar a atualização de estado entre os servidores. Os ser- vidores de backup podem derivar o estado de fluxo e o estado RTP a partir de um tempo de partida de uma transmissão RTSP particular. O aspecto principal de RTP consiste no fato de que a transmissão de dados RTP é baseada em tempo real. O estado de fluxo em qualquer ponto determinado a tempo é uma função de tempo e o estado RTSP. Os presentes princí- pios descrevem um método para derivar o estado de fluxo RTP.
Na breve descrição e referindo-se à Figura 1, um diagrama de uma rede de fluxo contínuo 100, conforme mostrado na técnica é mostrado. Inicialmente, um grupo de servidor 130 inclui um ou mais servidores de fluxo contínuo de protocole em tempo real (RTP) 131a- 131c, onde cada servidor de fluxo contínuo RTP 131a-131c é conectado através de uma rede 120 para um banco de dados de mídia 110. O banco de dados de mídia 110 contém serviços de vídeo e áudio capaz de serem transmitidos através da rede 120 como meio de fluxo contínuo.
Os servidores de fluxo contínuo RTP 131a-131c são conectados à Internet 150 (como um tipo de rede) através de um roteador 140, e através do qual os servidores de fluxo contínuo RTP 131a-131cse comunicam com uma pluralidade de clientes 161-161d.
Referindo-se à Figura 2, um diagrama de um sistema de rede de fluxo contínuo em tempo real 200, de acordo com um aspecto dos presentes princípios da invenção é mostra- do. Inicialmente, um grupo de servidor 130, que tem um ou mais servidores primários de fluxo contínuo 131a-131c é conectado a uma rede 120 através da qual os servidores de flu- xo contínuo 131a-131c podem acessar um banco de dados de mídia 110. Os servidores de fluxo contínuo 131a-131c também são conectados à Internet 150 (como um tipo de rede de comunicações) através de um roteador 140, ou similar, através do qual cada servidor 131a- 131c pode se comunicar de maneira bidirecional com um ou mais clientes 161a-161d.
Os presentes princípios incluem adicionalmente o grupo de servidor de backup 210 que tem um ou mais servidores RTP 211a-211c. Os servidores de backup são configurados para se comunicar através da rede 120 com um banco de dados de mídia acoplado 110, de modo que cada servidor de backup possa acessar conteúdos de áudio/vídeo do banco de dados de mídia 110. De maneira adicional, os servidores de backup 211a-211c também são configurados para se comunicar através do roteador 140 ao longo da Internet 150 com um ou mais clientes 161a-161d. De maneira alternativa, os servidores 131a-131c e os servido- res de backup 211a-211c podem se conectar ao roteador 140 e à Internet 150 através da rede 120. Os servidores de backup 211a-211c podem ser adicionalmente configurados para monitorar também o tráfego de rede que surge a partir de cada servidor primário 131a-131c. Os servidores de backup 211a-211c podem ser configurados para monitorar e registrar as informações que se referem à configuração de sessão de fluxo contínuo e estado de sessão de fluxo contínuo. De maneira adicional, os servidores de backup 211a-211c podem ser ca- pazes de se comunicar diretamente com os servidores primários 131a-131c.
Quando implementa uma técnica de monitoramento de rede, de acordo com os princípios da invenção, uma placa de rede de cada servidor de backup 211a-211c pode ser configurada no modo promíscuo, onde a placa de rede aceita todo o tráfego de rede que é transmitido para a placa, em vez de apenas o tráfego especificamente endereçado à placa de rede. Nesta implementação, os servidores de backup 211a-211c monitoram os servido- res primários específicos 131a-131c como parte de um grupo pode filtrar qualquer tráfego de rede que não se origina dos servidores primários 131a-131c que um servidor de backup par- ticular 211a-211c está monitorando. Deve-se notar, entretanto, que qualquer relação entre o número de servidores de backup 211a-211c e servidores primários 131a-131c pode ser van- tajosamente empregado. Por exemplo, para reduzir os custos de capital, apenas alguns ser- vidores de backup 211a-211c podem monitorar um grande número de servidores primários 131a-131c. Deste modo, o número de servidores de backup 211a-211c pode ser ajustado para proporcionar capacidade de recuperação após falha suficiente para um grande grupo de servidor primário 131a-131c.
Este conceito do número de servidor primário 131 a-131c versus o numero de ser- vidores de backup 211a-211c pode ser adicionalmente expandido em direção a uma situa- ção em que fluxos RTP diferentes são designados a diversas prioridades. Por exemplo, se um fluxo RTP associado a um vídeo de alta definição é transmitido para um cliente 161a ao mesmo tempo que um fluxo RTP separado associado ao áudio de baixa qualidade pode existir uma prioridade em que o fluxo de vídeo é mais importante que o fluxo de áudio. Por- tanto, observa-se que pode existir uma alocação feita para o tipo e/ou conteúdo de mídia que é distribuído, onde o meio de prioridade mais alta (vídeo) fica em mais servidores de backup RTP 211a-c que o meio de baixa prioridade (áudio de baixa qualidade). Esta deter- minação de prioridade pode ser feita em um banco de dados de mídia 110 por uma terceira parte que controla tanto os servidores primários 131a-131c como os servidores de backup 211a-c.
Referindo-se agora à Figura 3, um diagrama de bloco de um método 300 para a
migração (transferência) de um fluxo em tempo real para um ou mais servidores de backup 211a-211c, mediante uma falha de um servidor primário 131a-131c, de acordo com um as- pecto dos presentes princípios é mostrado.
Inicialmente, um fluxo RTP é iniciado no bloco 310. Em uma implementação útil, os servidores primários 131a-131c irão começar uma nova sessão com o cliente 161a-161d. Esta sessão pode ser vantajosamente iniciada pela solicitação de cliente 161a-161d, através de uma condição predeterminada que é encontrada, ou através de quaisquer outros meios conhecidos ou ainda não descobertos. Por exemplo, o cliente 161a-161d pode solicitar um vídeo a partir de um programa de televisão recente ao clicar em um hyperlink incorporado em uma página da web. Uma interface de usuário, então, pode ser exibida no cliente 161a- 161 d, permitindo que um usuário controle a exibição do meio de fluxo contínuo. Por exem- plo, após clicar em um link, um cliente pode abrir um tocador de mídia com uma área de exibição de mídia e controles associados, incluindo um botão reproduzir, botão pausar, linha de tempo de clipe de mídia, e similares. Tais interfaces são conhecidas e familiares para os versados na técnica.
Mediante o carregamento da interface de usuário adequada, a transferência de da- dos começa no bloco 310. Em uma implementação útil, os dados transferidos a partir do servidor 131a-131c para o cliente 161a-161d podem ser temporariamente armazenados por algum curto tempo no cliente 161a-161d antes de serem exibidos. Por exemplo, quando o usuário clica em um link para exibir um arquivo de mídia de fluxo contínuo, o arquivo de mí- dia é aberto em uma interface de tocador de mídia. O tocador de mídia, então, se conecta ao servidor 131a-131c, que solicita o arquivo desejado. Após o servidor confirmar a solicita- ção, o servidor 131a-131c começa a enviar os pacotes de dados contendo informações de mídia para o cliente que, então, são exibidos. A negociação da sessão de fluxo contínuo é considerada parte do início da sessão de fluxo contínuo. Igualmente, o estado RTSP é alte- rado para reproduzir, para começar a reprodução de mídia, se iniciada automaticamente, ou mediante o clique de um usuário em um botão reproduzir, ou similar.
A fim de rastrear adequadamente cada sessão, diversas informações devem ser armazenadas e disponíveis para quaisquer servidores de backup 211a-211c, que incluem, porém não se limitam a:
O identificador de Fonte de Envio (SSRC), conforme usado no cabeçalho RTP; O tipo de carga útil;
A localização do recurso que é transmitido (URL);
Os números de porta de servidor e cliente através da qual os dados estão sendo transmitidos;
A seqüência numérica do primeiro pacote RTP após o estado RTSP ter sido altera- do para reproduzir;
O carimbo de data/hora do primeiro pacote RTP após o estado RTSP ter sido alte- rado para reproduzir;
O tempo de rede (WT) quando o estado RTSP foi alterado para reproduzir;
O tempo de rede quando a sessão de fluxo contínuo, então, começou. Estas informações, entre outros métodos, podem ser comunicadas para os servido-
res de backup 131a-131c ao salvar as informações no local de rede comum que é acessível aos servidores de backup 211a-211c, ao transmitir as informações diretamente para os ser- vidores de backup 211a-211c, ou através dos servidores de backup 211a-211c que monito- ram o tráfego de rede dos servidores primários 131a-131c. De maneira adicional, a fim de calcular precisamente a migração (transferência) de
uma sessão de fluxo contínuo, todos os servidores primários 131a-131c e servidores de backup 211a- 211c podem usar a mesma base de tempo para calcular quaisquer tempos de rede ou carimbos de data/hora. Em uma implementação útil, os relógios internos dos servi- dores primários 131a-131c e servidores de backup 221a-221c podem ser coordenados u- sando o protocolo de tempo de rede (NTP) ao longo da rede 120.
Após o fluxo de dados ser iniciado no bloco 310, então, o servidor de backup 211a- 211c executa o ping nos servidores primários no bloco 330. Embora o termo ping possa ser usado para significar uma simples solicitação de eco de Protocolo de Mensagem de Contro- le de Internet (ICMP) que permite um servidor de ping verificar se o servidor alvo esta res- pondendo, o termo ping, neste caso, tem intenção de incluir qualquer forma de verificação de atividade de servidor. Em uma implementação útil, cada servidor primário pode radiodi- fundir um sinal de pulsação endereçado a um ou mais servidores de backup 211a-211c. Em outra implementação útil, o ping pode ser uma pequena solicitação que requer pouco ou nenhum processamento na parte do servidor alvo 131a-131c. Entretanto, um ping simples, tal como, uma solicitação de eco ICMP apenas verifica se o servidor está respondendo. Em- bora isto possa ser útil para verificar se um servidor primário 131a-131c estiver manuseando o tráfego, o mesmo não permite que a verificação do servidor que está sub um servidor de carga 131a-131c seja capaz de manuseio. Em tal caso, o ping pode ser, porém não se limi- ta, por exemplo, a uma solicitação para um clipe de mídia real ou outro recurso a partir do servidor primário 131a-131c, com o servidor de solicitação que mede o tempo de resposta, ou pode ser uma solicitação em que o servidor primário 131a-131c responde com um código de estado que indica se o servidor está funcionando atualmente de maneira adequada, ou está sobrecarregado. Deve-se entender que o termo ping também representa uma mensa- gem de estado que indica se um servidor está ativo ou inativo.
Em outra implementação útil, todo servidor de backup pode executar ping (comuni- car) com todo servidor primário em intervalos regulares para assegurar que todos os servi- dores primários estejam operando normalmente. Entretanto, à medida que o número de ser- vidores primários 131a-131c e o número de servidores de backup 211a-21c aumenta, o nú- mero total de solicitações de ping aumenta exponencialmente. Portanto, ainda em outra im- plementação útil, os servidores primários podem ser agrupados em clusters, com um cluster associado de servidores de backup 211a-211c. Por exemplo, em um centro de dados com 1.000 servidores primários 131a-131c, e 500 servidores de backup 211a-211c, 4 servidores primários podem ser agrupados juntos, e podem ser monitorados por 2 servidores de bac- kup. Deste modo, em cada cluster, apenas 8 solicitações de ping ocorrem toda vez que os servidores têm o ping executado no bloco 330 (com cada servidor de backup no cluster que executa o ping em cada servidor primário no cluster). Com 250 tais clusters, toda a carga de rede para executar o ping nos servidores no bloco 330 pode ser apenas 2.000 solicitações de ping. De modo oposto, se todos os 500 servidores de backup monitorarem todos os 1.000 servidores primários em tal rede, 500.000 solicitações de ping podem ser necessárias toda vez que os servidores tiverem o ping executado bloco 330. Embora o presente exemplo use clusters de 2 servidores de backup 211a-211c que monitoram um cluster de 4 servido- res primários 131a-131c, qualquer número ou configuração de servidores de backup 211a- 211c e servidores primários pode ser usado à medida que a redundância necessita e a ar- quitetura de rede dita.
Alternativamente, quando os servidores primários 131a-131c utilizam um sinal de pulsação, cada servidor primário 131a-131c pode transmitir um sinal de pulsação em inter- valos regulares no bloco 330 ao longo da rede 120, onde o sinal de pulsação pode ser rece- bido pelos servidores de backup 211a-211c que monitoram o tráfego de dados de servidor primário 131 a-131c através da rede 120 ou roteador 140.
Os servidores de backup 211a-211c, então, podem determinar, no bloco 340, se cada servidor primário 131 a-131c estava ativo /inativo. Em uma implementação útil, os servi- dores de backup podem medir o período de tempo necessário para receber uma resposta para o ping enviado para cada servidor primário 131 a-131c no bloco 330. A resposta de ping não deve ser recebida em um período de tempo especificado, os servidores de backup 211a-211c podem determinar que o servidor primário 131 a-131c que é analisado não está ativo e, então, migrar as sessões de fluxo RTSP do servidor primário em falha 131 a-131c para o servidor de backup 211a-211c. De maneira alternativa, em outra implementação útil, o servidor primário 131 a-131c que é analisado pode retornar uma resposta para o ping indi- cando que o servidor primário 131 a-131c está sobrecarregado, ou que o servidor experi- mentou algum tipo de falha de hardware ou software irrecuperável. Em tal caso, o servidor de backup 211a-211c também pode determinar que o servidor primário 131a-131c não está mais ativo no bloco 340.
De modo oposto, o servidor primário 131 a-131c deve enviar uma resposta adequa- da, ou uma resposta com um intervalo de tempo aceitável para os servidores de backup 211 a-211 c, então, os servidores de backup 211 a-211 c podem determinar de que o servidor primário se encontra ativo no bloco 340.
Se os servidores de backup 211 a 211c determinam no bloco 340 que o servidor primário 131 a-131c está ativo, então, o processo que verifica a atividade de servidor irá es- perar algum tempo limite especificado no bloco 320 antes de começar o processo de ping no bloco 330 novamente. Em implementações particularmente úteis, a duração do tempo limite no bloco 330 será curta o bastante para permitir que uma capacidade de recuperação após falha no servidor de backup 211 a-211c ocorra sem degradar a experiência de usuário.
Entretanto, deve-se determinar que um servidor não fique ativo no bloco 340, então, o servidor de backup 211 a-211c pode migrar as sessões de fluxo contínuo RTSP do servi- dor primário em falha 131 a-131c para o servidor de backup 211 a-211c ao assumir inicial- mente o endereço de protocolo de Internet (IP) do servidor primário em falha 131 a-131c no bloco 350, e migrar as conexões TCP ativas no bloco 360. O controle de endereço IP no bloco 350 e a migração de conexão TCP no bloco 360 são bem conhecidos e familiares pa- ra aqueles versados na técnica de comunicações de dados. Na prática, tal controle de ende- reço IP no bloco 350 e migração de conexão TCP no bloco 360 levam apenas alguns milis- segundos para serem realizados. Isto permite que um servidor de backup 211 a-211c repre- sente o servidor primário original não falhado 131a-131c.
O servidor de backup 211 a-211c, então, no bloco 370, pode executar um Ioop atra- vés de todas as sessões de fluxo contínuo RTSP ativas para o servidor primário em falha 131a-131c, e para cada sessão de fluxo contínuo ativa encontrada no bloco 370, o servidor de backup irá derivar um estado de sessão no bloco 380. TA derivação do estado de sessão no bloco 380 faz uso da informação coletada quando o fluxo foi iniciado no bloco 310. Ao usar tal informação com a última informação conhecida sobre o estado do fluxo reunido a partir do monitoramento do servidor primário 131 a-131c antes da falha, o servidor de backup pode derivar os próximos pacotes de dados que precisam ser enviados para o cliente 161a- 161c. Em uma implementação útil, a seguinte função pode ser usada para derivar o estado de fluxo:
[1] SN(X) = SN+ (X-SNM)
onde X representa o índice da amostra de mídia em um arquivo de mídia que preci- sa ser transmitido para o próximo cliente 11a-161c. SN(X) é a seqüência numérica atual a ser colocada no pacote RTP1 SN é a seqüência numérica do primeiro pacote RTP após o fluxo estado RTSP ter sido alterado para reproduzir, e SNM é o índice da amostra de mídia no pacote RTP quando o fluxo estado RTSP foi alterado para reproduzir. Portanto, (X - SNM) representa o número de amostras uma vez que o fluxo RTSP foi alterado para repro- duzir.
X pode ser determinado a partir de:
[2] TS(X) = TS(SNM) + D
onde TS(X) é o carimbo de data/hora de X, TS(SNM) é o carimbo de data/hora de SNM, e D é o tempo decorrido desde o estado RTSP ter sido alterado para reproduzir. D pode ser calculado por: [3] D = t - WT
onde 't' é o tempo de rede atual e, consequentemente, aproximadamente o momen- to em que o servidor primário 131 a-131c falhou, e WT é o tempo de rede que o estado de sessão RTSP alterou para reproduzir, e foi registrado no bloco 310, então, o fluxo iniciou.
Portanto, D representa o tempo total decorrido em que as amostras de mídia foram transmitidas antes de o servidor primário 131 a-131c falhar. TS(SNM) representa o carimbo de data/hora do primeiro pacote RTP enviado quando o RTSP foi alterado para reproduzir, e é usado como um deslocamento inicial para calcular o carimbo de data/hora atualmente ne- cessário de X (TS(X)). A seqüência numérica de X, (SN(X))1 é calculada separadamente. Usando o carim- bo de data/hora calculado para X, (TS(X))1 o servidor de backup 211a-211c pode mover o indicador de leitura de arquivo de mídia para o local da amostra X no arquivo de mídia, onde a amostra X tem o carimbo de data/hora TS(X). O servidor de backup, então, pode encontrar o número de série de X. O número de série do primeiro pacote RTP (SN) é usado como o deslocamento inicial para todo o fluxo no qual a seqüência numérica da amostra atual no arquivo de mídia atual (X-SNM) é adicionada.
Ao usar um deslocamento para toda a sessão de fluxo contínuo, assim como o des- locamento para o arquivo de mídia, múltiplos arquivos de mídia podem ser seqüencialmente transmitidos em uma única sessão, e o método 300 pode manusear a falha durante a repro- dução de um arquivo de mídia subsequente ao primeiro arquivo de mídia.
Uma vez que o estado de sessão de fluxo é derivado para cada sessão ativa no bloco 380, o servidor de backup transmite a amostra de mídia necessária no bloco 390, u- sando o endereço IP controlado no bloco 350 e ao longo da conexão migrada TCP no bloco 360.
As implementações preferidas foram descritas para um sistema e método para mo- nitorar um servidor de fluxo contínuo (que são projetados para serem ilustrativos e não Iimi- tativos), nota-se que modificações e variações podem ser feitas por aqueles versados na técnica à luz dos ensinamentos acima. Portanto, deve-se entender que alterações podem ser feitas nas implementações particulares dos presentes princípios descritos, que se en- contram dentro do escopo e espírito dos presentes princípios, conforme delineados pelas reivindicações em anexo. Desta forma, o presente princípio com os detalhes e particularida- des exigidos pelas leis de patente, apresenta-se o que se reivindica e se deseja proteger pela Autorização de Patentes nas reivindicações em anexo.
Claims (15)
1. Método para monitorar e migrar um fluxo de protocolo de fluxo contínuo em tem- po real (RTSP) que transmite pacotes de protocolo em tempo real (RTP) para um servidor de backup (211a-c), o método sendo CARACTERIZADO pelo fato de que compreende: abrir uma sessão de fluxo contínuo e iniciar um fluxo de transferência de dados a partir de um servidor primário (131 a-c) para um cliente (161a-d); executar o ping no servidor primário através de pelo menos um servidor de backup (211 a-c); determinar se o servidor primário (131 a-c) está ativo/inativo, sendo que mediante a determinação de que o servidor primário (131 a-c) está inativo: assumir o controle do endereço de protocolo de Internet (IP) do servidor primário (131 a-c) através de um servidor de backup; executar o Ioop através de pelo menos uma sessão de fluxo contínuo aberta do servidor primário (131 a-c); migrar a conexão de protocolo de controle de transmissão (TCP) a partir do servidor primário (131 a-c) para o servidor de backup (211 a-c); derivar o estado de fluxo de sessão RTP para cada sessão de fluxo contínuo aber- ta; e resumir o fluxo contínuo de sessão RTSP a partir do servidor de backup (211 a-c) para o cliente usando o estado de fluxo de sessão RTSP derivado.
2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que, mediante a determinação de que o servidor primário se encontra ativo, compreende: aguardar um tempo predeterminado; e retornar para a dita etapa de execução de ping no servidor primário através de pelo menos um servidor de backup.
3. Método, de acordo com a reivindicação 2, CARACTERIZADO pelo fato de que a dita abertura compreende adicionalmente: determinar e tornar disponível, através do servidor primário para os servidores de backup, uma seqüência numérica do primeiro pacote RTP após o estado RTSP ter sido alte- rado para reproduzir; determinar e tornar disponível, através do servidor primário para os servidores de backup, um carimbo de data/hora do primeiro pacote RTP após o estado RTSP ter sido alte- rado para reproduzir; determinar e tornar disponível através do servidor primário para os servidores de backup, um tempo de rede quando o estado RTSP foi alterado para reproduzir; e determinar e tornar disponível através do servidor primário para o servidores de backup, um tempo de rede quando, então, a sessão de fluxo contínuo começou.
4. Método, de acordo com a reivindicação 3, CARACTERIZADO pelo fato de que a dita derivação compreende adicionalmente: determinar uma seqüência numérica para o pacote RTP que tem uma amostra de mídia em um arquivo de mídia; e mover o indicador de leitura de arquivo para o arquivo de mídia até o local da amos- tra de mídia a ser transmitida com base no carimbo de data/hora da amostra de mídia;
5. Método, de acordo com a reivindicação 4, CARACTERIZADO pelo fato de que a determinação de uma seqüência numérica compreende: subtrair um índice de uma amostra de mídia em um pacote RTP quando o estado RTSPfoiaIterado para reproduzir, para determinar o número de pacotes de mídia transmiti- dos; e determinar a seqüência numérica de um pacote RTP que tem uma amostra de mí- dia a ser transmitida a seguir ao adicionar o número de pacotes de mídia transmitidos para a seqüência numérica do primeiro pacote RTP após o estado de fluxo alterar para reproduzir.
6. Método, de acordo com a reivindicação 4, CARACTERIZADO pelo fato de que o dito movimento de um indicador de leitura de arquivo compreende: calcular um tempo decorrido uma vez que o estado RTSP foi alterado para repro- duzir (o tempo decorrido) ao subtrair o tempo de rede que o estado de sessão RTSP alterou para reproduzir a partir do tempo de rede atual; calcular o carimbo de data/hora da amostra de mídia a ser transmitida ao adicionar o tempo decorrido ao carimbo de data/hora de uma amostra no arquivo de mídia no primeiro pacote RTP quando o estado de fluxo RTSP foi alterado para reproduzir; mover um indicador de leitura de arquivo para um arquivo de mídia até o local de arquivo de uma amostra de mídia que tem um carimbo de data/hora igual ao carimbo de data/hora do arquivo de mídia a ser transmitido.
7. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a dita execução de ping compreende: enviar uma mensagem de pulsação a partir do servidor primário; e aguardar a mensagem de pulsação em pelo menos um servidor de backup, o servi- dor de backup determina se o servidor primário está ativo/inativo através da falha para rece- ber a mensagem de pulsação em um tempo predeterminado.
8. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a execução de ping compreende: monitorar o tráfego de rede do servidor primário em pelo menos um servidor de backup, pelo menos um servidor de backup determina se o servidor primário está ati- vo/inativo através da falha do servidor de backup para detectar qualquer tráfego de rede a partir do servidor primário em um tempo predeterminado.
9. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que compreende adicionalmente monitorar uma pluralidade de clusters de servidor primário que tem uma pluralidade de servidores primários através de uma pluralidade de clusters de ser- vidor de backup que tem a pluralidade de servidores de backup, cada cluster de servidor de backup monitora um cluster de servidor primário.
10. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que compreende adicionalmente sincronizar os relógios internos dos servidores primários e dos servidores de backup com um tempo de rede comum que usa o Protocolo de Tempo de Re- de (NTP).
11. Método para monitorar, CARACTERIZADO pelo fato de que compreende: transmitir uma mensagem de consulta de estado a partir de um primeiro servidor (131a-c) a partir de um segundo servidor (211a-c) após uma sessão de fluxo contínuo ser iniciada com um cliente (161a-d); repetir a transmissão da dita mensagem de consulta de estado após um período de tempo quando a dita mensagem de estado, a partir do dito primeiro servidor (131a-c), indica que o dito primeiro servidor (131a-c) está em um estado ativo até pelo menos: a dita sessão de fluxo contínuo ser terminada com o dito cliente (161a-d) e a dita mensagem de estado indicar que o dito primeiro servidor (131a-c) está inativo; transmitir os dados para o dito cliente (161a-d) a partir do dito segundo servidor (211a-c), que representam dita sessão de fluxo contínuo, quando o dito primeiro servidor é reportado como inativo.
12. Método, de acordo com a reivindicação 11, CARACTERIZADO pelo fato de que a dita sessão de fluxo contínuo é uma sessão de fluxo contínuo de protocolo de fluxo contí- nuo em tempo real (RTSP) que transmite pacotes de protocolo em tempo real (RTP).
13. Método, de acordo com a reivindicação 12, CARACTERIZADO pelo fato de que, mediante uma determinação de que o primeiro servidor está inativo: a dita etapa de transmissão compreende substituir a sessão de fluxo contínuo RTSP do primeiro servidor com uma sessão de fluxo contínuo RTSP que se origina a partir do dito segundo servidor.
14. Método, de acordo com a reivindicação 13, CARACTERIZADO pelo fato de que a dita migração compreende: assumir o controle do endereço de protocolo de Internet (IP) do primeiro servidor a- través do dito segundo servidor de backup; migrar a conexão de protocolo de controle de transmissão (TCP) a partir do servidor primário para o servidor de backup; executar o Ioop através de pelo menos uma sessão de fluxo contínuo aberta do primeiro servidor; derivar um estado de fluxo de sessão RTSP; e resumir o fluxo contínuo de sessão RTSP a partir do segundo servidor para o clien- te usando o estado de fluxo de sessão RTSP derivado.
15. Método, de acordo com a reivindicação 14, CARACTERIZADO pelo fato de que uma pluralidade de clusters de servidor primário que tem uma pluralidade de servidores pri- mários, sendo que um dos servidores primários é o dito primeiro servidor, são monitorados pela pluralidade de clusters de servidor de backup que tem a pluralidade de servidores de backup, sendo que um dos servidores de backup é o dito segundo servidor e um cluster de servidor de backup monitora pelo menos um cluster de servidor primário.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/US2007/014991 WO2009002318A1 (en) | 2007-06-26 | 2007-06-26 | Real time protocol stream migration |
Publications (1)
Publication Number | Publication Date |
---|---|
BRPI0721658A2 true BRPI0721658A2 (pt) | 2013-01-22 |
Family
ID=39339779
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
BRPI0721658-0A BRPI0721658A2 (pt) | 2007-06-26 | 2007-06-26 | migraÇço de fluxo de protocolo em tempo real |
Country Status (7)
Country | Link |
---|---|
US (1) | US20100138531A1 (pt) |
EP (1) | EP2168360A1 (pt) |
JP (1) | JP2010531618A (pt) |
KR (1) | KR20100027162A (pt) |
CN (1) | CN101690136A (pt) |
BR (1) | BRPI0721658A2 (pt) |
WO (1) | WO2009002318A1 (pt) |
Families Citing this family (45)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8621275B1 (en) | 2010-08-06 | 2013-12-31 | Open Invention Network, Llc | System and method for event-driven live migration of multi-process applications |
US8584145B1 (en) | 2010-08-06 | 2013-11-12 | Open Invention Network, Llc | System and method for dynamic transparent consistent application-replication of multi-process multi-threaded applications |
US9043640B1 (en) * | 2005-08-26 | 2015-05-26 | Open Invention Network, LLP | System and method for event-driven live migration of multi-process applications |
CN101350741A (zh) * | 2007-07-20 | 2009-01-21 | 华为技术有限公司 | 实时流协议事件通知方法、装置及*** |
US8788589B2 (en) * | 2007-10-12 | 2014-07-22 | Watchitoo, Inc. | System and method for coordinating simultaneous edits of shared digital data |
WO2009047750A2 (en) * | 2007-10-12 | 2009-04-16 | Rony Zarom | System and method for synchronized video sharing |
US7986702B1 (en) * | 2007-11-29 | 2011-07-26 | Bigband Networks Inc. | Method and system for streaming multimedia transmissions |
US8640143B2 (en) * | 2008-02-12 | 2014-01-28 | International Business Machines Corporation | Method and system for providing preemptive response routing |
JP5075727B2 (ja) * | 2008-04-25 | 2012-11-21 | 株式会社日立製作所 | ストリーム配信システム及び障害検知方法 |
WO2010046722A1 (en) * | 2008-10-24 | 2010-04-29 | Telefonaktiebolaget L M Ericsson (Publ) | Systems and methods for reducing loss of service using protocol redirect functions |
EP2436168A2 (fr) * | 2009-05-29 | 2012-04-04 | France Telecom | Technique de distribution d'un contenu vers un utilisateur |
CN102238364A (zh) * | 2010-04-22 | 2011-11-09 | 上海国际技贸联合有限公司 | 轨道交通电视监控***中关键设备的冗余方法 |
EP2394703B1 (de) | 2010-06-14 | 2015-12-23 | Symrise AG | Kühlmischungen mit verstärkter Kühlwirkung von 5-Methyl-2-(propan-2-yl)cyclohexyl-N-ethyloxamat |
US9185054B2 (en) | 2010-09-15 | 2015-11-10 | Oracle International Corporation | System and method for providing zero buffer copying in a middleware machine environment |
US8856460B2 (en) | 2010-09-15 | 2014-10-07 | Oracle International Corporation | System and method for zero buffer copying in a middleware environment |
US8407776B2 (en) * | 2011-02-11 | 2013-03-26 | Good Technology Corporation | Method, apparatus and system for provisioning a push notification session |
US8521860B2 (en) | 2011-03-29 | 2013-08-27 | Microsoft Corporation | Providing a witness service |
CN102749978A (zh) * | 2011-04-20 | 2012-10-24 | 鸿富锦精密工业(深圳)有限公司 | 服务器 |
US8606825B1 (en) | 2011-07-20 | 2013-12-10 | Google Inc. | Query response streams based on dynamic query library |
US8887304B2 (en) | 2012-04-11 | 2014-11-11 | Comcast Cable Communications, Llc | System and method for processing user rights |
US8964736B1 (en) * | 2012-11-27 | 2015-02-24 | Sprint Communications Company L.P. | RTP streaming with dynamic packet format modification |
CN104782081B (zh) | 2013-01-27 | 2019-12-03 | 慧与发展有限责任合伙企业 | 用于转移套接字状态的***以及用于迁移tcp连接的方法 |
CN103152134B (zh) * | 2013-02-26 | 2015-12-02 | 汉柏科技有限公司 | 基于rtp协议的接收端重排语音包的方法和*** |
CN103618788A (zh) * | 2013-11-26 | 2014-03-05 | 曙光信息产业股份有限公司 | 一种支持b/s结构***高可用的方法 |
CN104967641B (zh) * | 2014-08-15 | 2017-06-23 | 浙江大华技术股份有限公司 | 一种实现主备元服务器数据同步的方法及装置 |
CN105791251B (zh) * | 2014-12-26 | 2019-02-05 | ***通信集团公司 | 一种网络业务迁移方法、装置和路由器 |
KR101641799B1 (ko) * | 2014-12-30 | 2016-07-29 | 주식회사 이노피아테크 | Tcp 세션을 복원하는 장애조치 시스템 및 방법 |
JP6343241B2 (ja) * | 2015-02-03 | 2018-06-13 | 日本電信電話株式会社 | ストリーミングサーバクラスタおよびそのストリーミング制御方法 |
US10230801B2 (en) * | 2015-04-14 | 2019-03-12 | Avaya Inc. | Session reconstruction using proactive redirect |
CN104811827A (zh) * | 2015-04-20 | 2015-07-29 | 中兴通讯股份有限公司 | 报文发送方法、码流处理方法及装置 |
US11659012B2 (en) * | 2015-06-15 | 2023-05-23 | Apple Inc. | Relayed communication channel establishment |
US10270903B2 (en) * | 2015-08-21 | 2019-04-23 | Avaya Inc. | Failover announcements |
CN105228021B (zh) * | 2015-09-30 | 2018-09-25 | 天脉聚源(北京)科技有限公司 | 一种电视互动***互动信息的传输方法 |
CN106856489B (zh) * | 2015-12-08 | 2020-09-08 | 阿里巴巴集团控股有限公司 | 一种分布式存储***的服务节点切换方法和装置 |
US10608998B2 (en) | 2016-04-29 | 2020-03-31 | Texas Instruments Incorporated | Enhanced network security using packet fragments |
TWI740885B (zh) * | 2017-01-23 | 2021-10-01 | 香港商阿里巴巴集團服務有限公司 | 分布式儲存系統的服務節點切換方法及裝置 |
US10812135B2 (en) | 2017-02-28 | 2020-10-20 | Texas Instruments Incorporated | Independent sequence processing to facilitate security between nodes in wireless networks |
US10419796B2 (en) | 2017-03-02 | 2019-09-17 | The Directv Group, Inc. | Broadband backup to satellite-based set-top boxes |
CN109218349A (zh) * | 2017-06-29 | 2019-01-15 | 北京微影时代科技有限公司 | 一种管理服务器集群的方法及装置 |
US11223515B2 (en) * | 2017-09-06 | 2022-01-11 | Nec Corporation | Cluster system, cluster system control method, server device, control method, and non-transitory computer-readable medium storing program |
KR102387935B1 (ko) * | 2017-10-23 | 2022-04-15 | 삼성전자주식회사 | 공용 메모리 영역 및 전용 메모리 영역을 포함하는 데이터 저장 장치 |
CN117242437A (zh) * | 2021-04-27 | 2023-12-15 | Abb瑞士股份有限公司 | 用于使用时间敏感网络控制通信网络中的冗余功能的方法和*** |
CN114095739B (zh) * | 2021-10-18 | 2023-08-01 | 海南车智易通信息技术有限公司 | 一种视频直播*** |
CN113992949B (zh) * | 2021-10-28 | 2023-04-28 | 广州华多网络科技有限公司 | 混流服务切换方法及其装置、设备、介质、产品 |
US20230208923A1 (en) * | 2021-12-29 | 2023-06-29 | Centurylink Intellectual Property Llc | System and method for transferring a client connection |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH10320323A (ja) * | 1997-05-15 | 1998-12-04 | Hewlett Packard Japan Ltd | サーバコンピュータ、サーバコンピュータの制御方法、およびサーバコンピュータを制御するためのプログラムを記録した記録媒体 |
US6934756B2 (en) * | 2000-11-01 | 2005-08-23 | International Business Machines Corporation | Conversational networking via transport, coding and control conversational protocols |
US6910078B1 (en) * | 2001-11-15 | 2005-06-21 | Cisco Technology, Inc. | Methods and apparatus for controlling the transmission of stream data |
US20060146784A1 (en) * | 2001-11-16 | 2006-07-06 | Ibasis, Inc. | System and method for monitoring a voice over internet protocol (VoIP) system |
US7076555B1 (en) * | 2002-01-23 | 2006-07-11 | Novell, Inc. | System and method for transparent takeover of TCP connections between servers |
JP3872410B2 (ja) * | 2002-10-21 | 2007-01-24 | 日本電信電話株式会社 | ストリーム中継制御方法、装置、およびプログラム |
JP2005242662A (ja) * | 2004-02-26 | 2005-09-08 | Japan Telecom Co Ltd | 通信システム |
JP2005250626A (ja) * | 2004-03-02 | 2005-09-15 | Hitachi Ltd | コンピュータシステム及びそのプログラム。 |
JP2005250625A (ja) * | 2004-03-02 | 2005-09-15 | Susumu Takase | 会費決済システム |
JP2006013912A (ja) * | 2004-06-25 | 2006-01-12 | Nippon Telegr & Teleph Corp <Ntt> | ストリームデータ配信方法、ストリームデータ配信装置、ストリームデータ制御装置、プログラム、および記録媒体 |
US7865765B2 (en) * | 2005-06-09 | 2011-01-04 | International Business Machines Corporation | Grid licensing server and fault tolerant grid system and method of use |
-
2007
- 2007-06-26 BR BRPI0721658-0A patent/BRPI0721658A2/pt not_active IP Right Cessation
- 2007-06-26 WO PCT/US2007/014991 patent/WO2009002318A1/en active Application Filing
- 2007-06-26 CN CN200780053537A patent/CN101690136A/zh active Pending
- 2007-06-26 JP JP2010514717A patent/JP2010531618A/ja active Pending
- 2007-06-26 KR KR1020097027064A patent/KR20100027162A/ko not_active Application Discontinuation
- 2007-06-26 US US12/452,110 patent/US20100138531A1/en not_active Abandoned
- 2007-06-26 EP EP07835901A patent/EP2168360A1/en not_active Withdrawn
Also Published As
Publication number | Publication date |
---|---|
CN101690136A (zh) | 2010-03-31 |
JP2010531618A (ja) | 2010-09-24 |
EP2168360A1 (en) | 2010-03-31 |
US20100138531A1 (en) | 2010-06-03 |
WO2009002318A1 (en) | 2008-12-31 |
KR20100027162A (ko) | 2010-03-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
BRPI0721658A2 (pt) | migraÇço de fluxo de protocolo em tempo real | |
EP2197179B1 (en) | Apparatus and method for fast detection of communication path failures | |
US8959395B2 (en) | Method and system for providing high availability to computer applications | |
US7257731B2 (en) | System and method for managing protocol network failures in a cluster system | |
JP5550793B2 (ja) | ネットワーク要素のサービス回復のための方法およびシステム | |
BR112012008313B1 (pt) | sistema e método de proteção ativa/standby para serviços de multicast do lado do usuário e dispositivo de roteamento | |
WO2012167625A1 (zh) | 分布式存储***及其时间戳的实现方法 | |
US20080205406A1 (en) | Recording medium having reception program recorded therein, recording medium having transmission program recorded therein, transmission/reception system and transmission/reception method | |
Ayari et al. | Fault tolerance for highly available internet services: concepts, approaches, and issues | |
JP2024517128A (ja) | クロック同期エッジベースのネットワーク機能 | |
US20190334761A1 (en) | Method and system for single web application recovery on a collaborative platform | |
JP2009238098A (ja) | セッション管理方法、ストレージ装置、及び、計算機システム | |
Lin et al. | Fast, scalable and robust centralized routing for data center networks | |
Price et al. | Adapting to NAT timeout values in P2P overlay networks | |
Marwah et al. | A system demonstration of ST-TCP | |
Ayari et al. | T2cp-ar: A system for transparent tcp active replication | |
Fujita et al. | TCP connection scheduler in single IP address cluster | |
Jin et al. | A fault-tolerant TCP scheme based on multi-images | |
JP2023087144A (ja) | ネットワーク管理システムおよびネットワーク管理プログラム | |
Teklemariam et al. | Transparent Recovery of Dynamic States on Constrained Nodes through Deep Packet Inspection | |
Aghdaie et al. | Efficient client-transparent fault tolerance for video conferencing. | |
JP2008242685A (ja) | フェイルオーバ方法、クラスタシステム、情報処理装置、プログラム | |
Bakke et al. | Middleware for transparent TCP connection migration: masking faulty TCP-based services | |
JPWO2010134177A1 (ja) | オペレーティングシステム実行装置及びパケット特定プログラム及び記録媒体及びパケット特定方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
B08F | Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette] |
Free format text: REFERENTE A 8A ANUIDADE. |
|
B08K | Patent lapsed as no evidence of payment of the annual fee has been furnished to inpi [chapter 8.11 patent gazette] |
Free format text: EM VIRTUDE DO ARQUIVAMENTO PUBLICADO NA RPI 2312 DE 28-04-2015 E CONSIDERANDO AUSENCIA DE MANIFESTACAO DENTRO DOS PRAZOS LEGAIS, INFORMO QUE CABE SER MANTIDO O ARQUIVAMENTO DO PEDIDO DE PATENTE, CONFORME O DISPOSTO NO ARTIGO 12, DA RESOLUCAO 113/2013. |