Trabalho a ser desenvolvido conform texto a seguii:
Sincronização de relógios
A sincronização de relógios em sistemas distribuídos [1] é relevante para inúmeras aplicações, particularmente quando é necessário determinar de forma global a ordem em que eventos aconteceram. Uma forma de ordenar eventos distribuídos ao longo do tempo basia-se na sincronização dos relógios nos diversos nós que compõem o sistema.
Embora os relógios em todos os equipamentos possam ser sincronizados no início da operação de um sistema, diferenças nos mecanismos de contagem dos relógios desses nós podem levar a variações crescentes em seus horários locais ao longo do tempo.
Diversos mecanismos existem para a sincronização de relógios, podendo basear-se em algoritmos centralizados e distribuídos.
O algoritmo de Christian [2] foi projetado para a atualização do horário em nós clientes a partir do horário de um servidor, o qual possui uma fonte externa para ajuste preciso de seu relógio. O protocolo Daytime [3,4], por exemplo, segue o algoritmo de Christian e usa um servidor centralizado que pode ser consultado pelos clientes para obtenção da hora atual. Nesse protocolo, comunicações com UDP e TCP podem ser usadas para a obtenção de uma mensagem em formato texto (ASCII) contendo o instante atual.
Dois tipos de mensagem são comuns no protocolo Daytime:
• Weekday, Month Day, Year Time-Zone
Example: Tuesday, February 22, 1982 17:37:43-PST
• dd mmm yy hh:mm:ss zzz
Example: 02 FEB 82 07:59:01 PST
Time Protocol [5,6] é outro exemplo de protocolo usado para ajustes de horário a partir de um servidor central. Nesse caso, ao ser consultado, via TCP ou UDP, o servidor envia informações sobre seu horário atual, na forma de um valor de 32 bits. O valor informado corresponde ao número de segundos a partir de meia-noite (00:00) de 1/01/1900. Por limitações do número de bits utilizado, esse protocolo só pode ser usado até o ano 2036.
Por exemplo, 2,208,988,800 corresponde a 00:00 1 Jan 1970 GMT.
2,398,291,200 corresponde a 00:00 1 Jan 1976 GMT.
2,524,521,600 corresponde a 00:00 1 Jan 1980 GMT.
2,629,584,000 corresponde a 00:00 1 May 1983 GMT.
Nesses dois protocolos (Daytime e Time), cabe ao nó cliente acrescentar ao tempo informado pelo servidor o tempo gasto desde a geração da mensagem no servidor até o seu recebimento pelo cliente. Uma fórmula comum para o cálculo desse tempo consiste em medir a variação no tempo local entre a emissão da consulta e o recebimento da resposta. Chamado de RTT (Round-Trip Time), esse valor representa, de maneira aproximada, duas vezes o tempo gasto para a propagação da resposta do servidor até o nó local. Assim, é comum somar-se metade do valor do RTT ao tempo informado pelo servidor ao ajustar-se o horário local.
O uso do valor de RTT considera que, de maneira geral, um pacote segue caminhos semelhantes na comunicação de ida e volta entre os nós. Além disso, medidas frequentes do valor de RTT podem determinar o valor mais apropriado para uso nos cálculos. De todo modo, a validade dos resultaos obtidos com essa forma de medição está limitada aos casos em que o valor de RTT é pequeno comparado com a precisão buscada.
Valores mais precisos para o RTT podem ser calculados considerando o histórico dos últimos valores obtidos e ponderando-se a influência de cada novo valor na estimativa global. Essa forma de cálculo é usada no protocolo TCP, por exemplo [7]:
onde α é uma constante de peso (0 ≤ α < 1). Se α é próximo de 0, valoriza-se as variações instantâneas do RTT, ocorrendo o contrário quando α é próximo de 1.
Em situações em que não há uma fonte de hora externa precisa para sincronização centralizada do horário em todos os nós, soluções distribuídas podem ser aplicadas. O algoritmo de Berkeley [8] pode ser usado nesses casos.
Nesse algoritmo, considera-se que nenhum nó possui o horário preciso. Deste modo, o horário global é determinado como o valor médio dos horários de todos os nós.
Para tanto, periodicamente, um nó, escolhido como mestre, consulta todos os demais nós para obter seus horários. Valores muito discrepantes são descartados e o valor médio é determinado, considerando também o efeito de RTT na interação com cada nó. Ao invés de propagar o novo valor do horário para cada nó, contudo, o servidor apenas informa a cada um deles qual é a variação que deve ser aplicada ao horário local, seja ela positiva ou negativa.
[from Wikipedia]
• A master is chosen via an election process such as Chang and Roberts algorithm.
• The master polls the slaves who reply with their time in a similar way to Cristian's algorithm.
• The master observes the round-trip time (RTT) of the messages and estimates the time of each slave and its own.
• The master then averages the clock times, ignoring any values it receives far outside the values of the others.
• Instead of sending the updated current time back to the other process, the master then sends out the amount (positive or negative) that each slave must adjust its clock. This avoids further uncertainty due to RTT at the slave processes.
Uma questão a considerar, contudo, é que não é desejável atrasar o relógio do sistema, já que isso poderia causar eventos com tempos de ocorrência no futuro. Para evitar simplesmente parar o relógio durante o período necessário, sistemas costumam reduzir a taxa de incremento até que o valor apropriado seja atingido.
Atividade
Usando o mecanismo de comunicação baseado em sockets e a arquitetura de protocolos TCP/IP, você deve criar um serviço desincronização de relógios em rede. Como não há uma fonte centralizada para sincronização nesse caso, o ajuste dos relógios deve ser realizado de forma distribuída, de acordo com o algoritmo de Berkeley.
Para a escolha do nó mestre, uma opção é fazer com que cada nó consulte os demais sistemas em que esse serviço está ativo na rede local e, usando um critério de antiguidade, por exemplo, decida-se quem será o mestre. Esse procedimento deve ser repetido toda vez que um novo nó for ativado no sistema e, por questões de tolerância a falhas, sempre que o nó mestre deixar de responder.
Atualizações do horário devem ocorrer a cada 1 minuto.
Pergunta
magnon_lpf
Trabalho a ser desenvolvido conform texto a seguii:
Sincronização de relógios
A sincronização de relógios em sistemas distribuídos [1] é relevante para inúmeras aplicações, particularmente quando é necessário determinar de forma global a ordem em que eventos aconteceram. Uma forma de ordenar eventos distribuídos ao longo do tempo basia-se na sincronização dos relógios nos diversos nós que compõem o sistema.
Embora os relógios em todos os equipamentos possam ser sincronizados no início da operação de um sistema, diferenças nos mecanismos de contagem dos relógios desses nós podem levar a variações crescentes em seus horários locais ao longo do tempo.
Diversos mecanismos existem para a sincronização de relógios, podendo basear-se em algoritmos centralizados e distribuídos.
O algoritmo de Christian [2] foi projetado para a atualização do horário em nós clientes a partir do horário de um servidor, o qual possui uma fonte externa para ajuste preciso de seu relógio. O protocolo Daytime [3,4], por exemplo, segue o algoritmo de Christian e usa um servidor centralizado que pode ser consultado pelos clientes para obtenção da hora atual. Nesse protocolo, comunicações com UDP e TCP podem ser usadas para a obtenção de uma mensagem em formato texto (ASCII) contendo o instante atual.
Dois tipos de mensagem são comuns no protocolo Daytime:
• Weekday, Month Day, Year Time-Zone
Example: Tuesday, February 22, 1982 17:37:43-PST
• dd mmm yy hh:mm:ss zzz
Example: 02 FEB 82 07:59:01 PST
Time Protocol [5,6] é outro exemplo de protocolo usado para ajustes de horário a partir de um servidor central. Nesse caso, ao ser consultado, via TCP ou UDP, o servidor envia informações sobre seu horário atual, na forma de um valor de 32 bits. O valor informado corresponde ao número de segundos a partir de meia-noite (00:00) de 1/01/1900. Por limitações do número de bits utilizado, esse protocolo só pode ser usado até o ano 2036.
Por exemplo, 2,208,988,800 corresponde a 00:00 1 Jan 1970 GMT.
2,398,291,200 corresponde a 00:00 1 Jan 1976 GMT.
2,524,521,600 corresponde a 00:00 1 Jan 1980 GMT.
2,629,584,000 corresponde a 00:00 1 May 1983 GMT.
Nesses dois protocolos (Daytime e Time), cabe ao nó cliente acrescentar ao tempo informado pelo servidor o tempo gasto desde a geração da mensagem no servidor até o seu recebimento pelo cliente. Uma fórmula comum para o cálculo desse tempo consiste em medir a variação no tempo local entre a emissão da consulta e o recebimento da resposta. Chamado de RTT (Round-Trip Time), esse valor representa, de maneira aproximada, duas vezes o tempo gasto para a propagação da resposta do servidor até o nó local. Assim, é comum somar-se metade do valor do RTT ao tempo informado pelo servidor ao ajustar-se o horário local.
O uso do valor de RTT considera que, de maneira geral, um pacote segue caminhos semelhantes na comunicação de ida e volta entre os nós. Além disso, medidas frequentes do valor de RTT podem determinar o valor mais apropriado para uso nos cálculos. De todo modo, a validade dos resultaos obtidos com essa forma de medição está limitada aos casos em que o valor de RTT é pequeno comparado com a precisão buscada.
Valores mais precisos para o RTT podem ser calculados considerando o histórico dos últimos valores obtidos e ponderando-se a influência de cada novo valor na estimativa global. Essa forma de cálculo é usada no protocolo TCP, por exemplo [7]:
RTT = (α • RTT_atual) + ((1 − α) • Nova_amostra_do_RTT)
onde α é uma constante de peso (0 ≤ α < 1). Se α é próximo de 0, valoriza-se as variações instantâneas do RTT, ocorrendo o contrário quando α é próximo de 1.
Em situações em que não há uma fonte de hora externa precisa para sincronização centralizada do horário em todos os nós, soluções distribuídas podem ser aplicadas. O algoritmo de Berkeley [8] pode ser usado nesses casos.
Nesse algoritmo, considera-se que nenhum nó possui o horário preciso. Deste modo, o horário global é determinado como o valor médio dos horários de todos os nós.
Para tanto, periodicamente, um nó, escolhido como mestre, consulta todos os demais nós para obter seus horários. Valores muito discrepantes são descartados e o valor médio é determinado, considerando também o efeito de RTT na interação com cada nó. Ao invés de propagar o novo valor do horário para cada nó, contudo, o servidor apenas informa a cada um deles qual é a variação que deve ser aplicada ao horário local, seja ela positiva ou negativa.
[from Wikipedia]
• A master is chosen via an election process such as Chang and Roberts algorithm.
• The master polls the slaves who reply with their time in a similar way to Cristian's algorithm.
• The master observes the round-trip time (RTT) of the messages and estimates the time of each slave and its own.
• The master then averages the clock times, ignoring any values it receives far outside the values of the others.
• Instead of sending the updated current time back to the other process, the master then sends out the amount (positive or negative) that each slave must adjust its clock. This avoids further uncertainty due to RTT at the slave processes.
Uma questão a considerar, contudo, é que não é desejável atrasar o relógio do sistema, já que isso poderia causar eventos com tempos de ocorrência no futuro. Para evitar simplesmente parar o relógio durante o período necessário, sistemas costumam reduzir a taxa de incremento até que o valor apropriado seja atingido.
Atividade
Usando o mecanismo de comunicação baseado em sockets e a arquitetura de protocolos TCP/IP, você deve criar um serviço desincronização de relógios em rede. Como não há uma fonte centralizada para sincronização nesse caso, o ajuste dos relógios deve ser realizado de forma distribuída, de acordo com o algoritmo de Berkeley.
Para a escolha do nó mestre, uma opção é fazer com que cada nó consulte os demais sistemas em que esse serviço está ativo na rede local e, usando um critério de antiguidade, por exemplo, decida-se quem será o mestre. Esse procedimento deve ser repetido toda vez que um novo nó for ativado no sistema e, por questões de tolerância a falhas, sempre que o nó mestre deixar de responder.
Atualizações do horário devem ocorrer a cada 1 minuto.
Link para o comentário
Compartilhar em outros sites
0 respostass a esta questão
Posts Recomendados
Participe da discussão
Você pode postar agora e se registrar depois. Se você já tem uma conta, acesse agora para postar com sua conta.