Você está na página 1de 7

UNIVERSIDADE ESTADUAL DO AMAZONAS

ESCOLA SUPERIOR DE TECNOLOGIA

SISTEMAS DISTRIBUDOS
LISTA 3 CAPTULO 4

LETCIA MEDEIROS CORRS 1215080286

MANAUS, 2016

4.1 Se vrios processos compartilham uma porta, em seguida, deve ser possvel para todos as
mensagens que chegam nessa porta para ser recebido e processado de forma independente por
esses processos. Processos no costumam compartilhar dados, mas que partilham uma porta
faria requer acesso a dados ordinrias representativas das mensagens na fila no porto. Alm
disso, a estrutura da fila seria complicada pelo fato de que cada processo tem sua prpria ideia
da frente da fila, e quando a fila est vazia. Nota-se que um grupo de portas pode ser usado para
permitir que vrios processos para recebam a mesma mensagem.

4.2 As principais questes de projeto para localizar as portas do servidor so:


(i) Como que um cliente sabe o porta eo endereo IP para usar para atingir um servio?
As opes so:
usar um servidor de nome / ligante para mapear o nome textual de cada
servio sua porta
cada servio usa bem conhecido id porta independente do local, o que evita
uma pesquisa em um servidor de nomes.
O sistema operacional ainda tem de olhar para cima o paradeiro do servidor, mas a resposta
pode ser armazenada em cache localmente.
(ii) Como podem diferentes servidores oferecem o servio em momentos diferentes?
Identificadores de porta independentes do local do servio para permitir que tm a mesma porta
em diferentes locais. Se um ligante usado, o cliente precisa voltar a consultar o cliente para
encontrar o novo local.
(iii) Eficincia de acesso aos portos e identificadores locais.
s vezes, os sistemas operacionais permitem que os processos de usar nomes locais eficientes
para se referir aos portos. Isto torna-se um problema quando um servidor cria uma porta nopblica para um determinado cliente para enviar mensagens para, porque o nome local
insignificante para o cliente e tem de ser traduzido para um identificador global para utilizao
pelo cliente.

4.3 Para que esse teste seja executado, um processo envia e outro recebe. Modifiquei no
programa da figura 4.3 de modo que os argumentos do programa: especifique o hostname do
servidor, a porta do servidor, o nmero de n mensagens a ser enviado e o tamanho, L da
mensagem.
Se os argumentos no so adequados o programa deve sair imediatamente. O programa deve
abrir um socket datagrama e enviar n UDP mensagens datagrama para o servidor. Mensagem i
deve conter o nmero inteiro i nos primeiros 4 bytes e o carcter * no restante 1-4 bytes.
Ele no tenta receber mensagens.
No programa na figura 4.4 deve ser modificado de modo que o argumento do programa
especifique a porta do servidor. O programa abre um socket na porta dada e, em seguida, recebe
repetidamente um mensagem datagrama. Verifica o nmero em cada mensagem e relata sempre
que houver uma lacuna na sequncia de nmeros das mensagens recebidas de um cliente
particular.

4.4 Foi feita as seguintes modificaes no programa:


Datagramsocket a socket = new datagramsocket()
Socket.setSoTimeout (3000)
While {
Try{
Socket.Send(request)
Socket.receive(reply)
}catch (InterruptedIOException e)
{System.out.println("server not responding)
}
4.5 Nos dois programas uma sequncia de bytes transmitido a partir de um emissor
para um receptor, no caso de um remetente de uma mensagem primeiro constri a
sequncia de bytes e em seguida transmite para o receptor. J no caso de um
transmissor, transmite sempre os bytes quando esto prontos e o receptor coleta os bytes
do fluxo que chegam.
4.6 Quando executados por um tempo determinado ou de tempos em tempos o processo de
escrita falha, retorna a exceo IOException e quando o processo de leitura falha, o leitor
retorna a exceo EOF.
4.7 O mtodo XDR utiliza um formulrio padro e se torna ineficiente quando a comunicao
ocorre entre pares de computadores similares mas se torna eficiente quando usa-se a forma
padro na ordenao dos bytes. O corba CDR, para os remetentes incluem um identificador para
cada mensagem e receptores convertem os bytes para serem ordenados. Este mtodo elimina
todas as converses de dados desnecessrios mas aumenta a complexidade em que todos os
computadores precisam lidar com ambas.
4.8 O CDR define uma representao para as ordens big-endian e little-endian. Os valores so
transmitidos na ordem do remetente, que especificada em cada mensagem. Se exigir uma
ordem diferente, o destinatrio a transforma.
O XDR ele foi desenvolvido pela Sun para uso nas mensagens trocadas entre clientes e
servidores NFS. A mensagem consiste em uma sequncia de objetos de 4 bytes usando uma
conveno que um cardinal ou inteiro ocupa um objeto e que sequncias de quatro caracteres
tambm ocupam um objeto, os caracteres so em cdigo ASCII.
4.9 A representao usada pelo CORBA inclui apenas os valores dos objetos transmitidos nada
a respeito de seus tipos. uma representao externa dos tipos estruturados e primitivos que
podem ser passados como argumentos e resultados na invocao a mtodos remotos no
CORBA. E pode ser usada por diversas linguagens de programao.

4.10 O algoritmo abaixo descreve serializao de um objeto, como escrever suas informaes de
classe seguido por os nomes e os tipos das variveis de instncia. Em seguida, serializa cada
varivel de instncia recursivamente.
serialize(Object o) {
c = class(o)
class_handle = get_handle(c)
If (class_handle==null) // Escrever informaes de classe e definir class_handle
write class_handle
write number (n), name and class of each instance variable
object_handle = get_handle(o)
If (object_handle==null) {
define object_handle
for (iv = 0 to n-1)
if (primitive(iv) ) write iv
else serialize( iv)
}
write object_handle
}
Descrever o formulrio serializado o algoritmo produziria ao serializar uma instncia da classe
Couple.
Por exemplo, declare uma instncia de Couple como:
Couple t1 = new Couple(new Person("Smith", "London", 1934),
new Person("Jones", "Paris", 1945))
A sada ser:
Valores serializados
Couple 8 byte version number h0
2 Person one Person two number,
instance
variables
Person 8 byte version number h1
3 int year
java.lang.String place
1934 5 Smith 6 London h2
h1
Couple
1945 5 Jones 5 Paris h3

Explicao:
class name, version number, handle
type and name

serialize instance variable


Couple
java.lang.String

one

of

of

name

serialize instance variable two of


values of instance variables

4.11 A classe abaixo representa instancias de objetos remotos:


Quando um objeto desserializado, a JVM tenta reconstitu-lo criando um novo
objeto o acervo que tenha o mesmo estado que objeto serializado tinha na hora em que
foi serializado. Exceto pelas variveis transientes, que so reconstitudas com nulo (para
referncias de objeto) ou com valores primitivos padro.
Assim os passos para se realizar uma desserializao, so:
1. Criar classe de desserializao
2. Criar construtor a partir de variveis de instancia
3. Criar nova instancia da classe, a partir do construtor e atributos da classe

A sada do algoritmo ser os valores de antes da serializao.


4.12. Devido ao fato dos documentos XML serem textuais. Uma das vantagens dessa
abordagem na ocorrncia de falhas, pois a capacidade de ler cdigo XML pode ser til
no entendimento dos problemas sofridos pelas falhas. Alm disso, o uso de texto torna a
XML independente de qualquer plataforma especfica. J as desvantagens, se d
justamente pelo uso de uma representao textual, em vez de binria, junto com o uso
de tags, tornando as mensagens muito maiores, o que faz com que elas exijam tempos
de processamento e transmisso maiores, assim como mais espao de armazenamento.
4.13. Classe que representa uma referencia a um objeto remoto
public class ObjetoRemoto{
private String endIP
private String numPorta
private String hora
private int numObj
//construtor
//getters e setters
}
Os mtodos utilizados para a comunicao com o Protocolo de Requisio Resposta
so:
public byte[ ] doOperation (RemoteRef s, int operationId, byte[ ] arguments){
Envia uma mensagem de requisio para o servidor remoto e retorna a
resposta.
Os argumentos especificam o servidor remoto, a operao a ser invocada
e os argumentos dessa operao.
}
public byte[ ] getRequest ( ){
L uma requisio do cliente por meio da porta do servidor.
}
public void sendReply (byte[ ] reply, InetAddress endIP, int numPorta){
Envia a mensagem de resposta reply para o cliente como seu endereo de
Internet e porta
}
4.14. A partir do cdigo da Figura 4.14, pode-se constatar que o multicast IP realmente
sofre falhas por omisso. Para os envios multicast feitos em uma rede local que possui
suporte nativo para que um nico datagrama chegue a vrios destinos, qualquer um
desses processos pode, individualmente, descartar a mensagem porque seu buffer est
cheio. Alm disso, um datagrama enviado de um roteador multicast para outro pode ser
perdido, impedindo, assim, que todos os destinos que estejam alm desse roteador
recebam a mensagem. Outro fator que qualquer processo pode falhar. Se um roteador
multicast falhar, os membros do grupo que estiverem alm desse roteador no recebero
a mensagem, embora os membros locais possam receber.
4.15. De acordo com o capitulo 4, para projetar um sistema que utilize retransmissores
de mensagens multicast superando o problema de mensagens descartadas, os padres
seguintes devero ser seguidos:
1. Tolerncia a falhas baseadas em servios replicados: considerando um servio
replicado que consiste nos membros de um grupo de servidores que comeam no

mesmo estado inicial e sempre executam as mesmas operaes, na mesma ordem, de


modo a permanecerem consistentes uns com os outros. A aplicao multicast impe que
todas as rplicas, ou nenhuma delas, devam receber cada pedido para executar uma
operao se uma perder um pedido, ela se tornar inconsistente com relao s outras.
2. Localizao dos servidores de descoberta na interligao em rede espontnea:
desde que qualquer processo que queira localizar os servidores de descoberta faa, aps
sua inicializao, o envio peridico de requisies em multicast, uma requisio
ocasionalmente perdida no ser um problema na localizao de um servidor de
descoberta.
3. Melhor desempenho atravs de dados replicados: considerando que os
prprios dados replicados, em vez de as operaes sobre eles, so distribudos por meio
de mensagens de multicast. O efeito de mensagens perdidas e ordem inconsistente
dependeria do mtodo de replicao e da importncia de todas as rplicas estarem
totalmente atualizadas.
A partir desses padres, tem-se o seguinte esquema:
1. Processo remetente designa um nmero de sequncia para as
mensagens
2. Mensagens so recebidas na ordem
3. Cada mensagem armazenada em buffer no remetente.
4. Mensagem mantida em buffer at que todos os clientes confirmem
recebimento de cada mensagem.
Retransmisso: reconhecimento negativo
4.16. O modelo de falhas multicast IP sofre falhas por omisso e difere da definio de
multicast confivel pois, em um multicast confivel, qualquer mensagem transmitida ou
recebida por todos os membros ou no recebida por nenhum deles enquanto que pelo
modelo de falhas pode haver descarte da mensagem no caso de buffer cheio e pode
haver a perda de datagrama, impossibilitando o recebimento do mesmo para destinos
alm de um roteador X.
4.17 Os destinos poderiam remediar essa situao fazendo uso do multicast totalmente
ordenado, onde todas as mensagens transmitidas para um grupo chegam a todos os
membros na mesma ordem.
4.18.O impacto das redes de sobreposio em relao aos desenvolvedores de
sobreposio que eles esto livres para redefinir os elementos bsicos de uma rede,
conforme mencionado no capitulo 3, inclusive o modo de endereamento, os protocolos
empregados e a estratgia de roteamento, frequentemente introduzindo estratgias
radicalmente diferentes, mais personalizadas para os tipos de aplicativo especficos dos
ambientes operacionais.

4.19 So citados os fatores: falta de necessidade de modificar a arquitetura bsica da


Internet chamada estabelecida sem a necessidade de IP ou porta para estabelec-la uso
de tecnologia peer-to-peer para trafego de dados.
4.20 Considerando que o destinatrio esteja pronto para receber no momento do envio, a
implementao subjacente pode ser otimizada, pois no h necessidade de verificar se
existe um buffer disponvel para receber a mensagem, evitando um handshake.
Claramente, essa uma operao muito perigosa, que vai falhar se a suposio a
respeito de estar pronto for invlida. Mais especificamente, essas otimizaes tratam-se
de um suporte flexvel para a passagem de mensagens, junto a suporte adicional para
passagem de mensagens por comunicao coletiva.