Netcabo Wars - NeoToPower contra-ataca :P

tal qual como está no texto... ;)

O TTL,passo a explicar....

Vamos supor que fazes um Ping, a um IP qualquer, que de momento não existe...

Achas que o pacote de 48b vai ficar eternamente "à procura" do IP de destino?

É extinto ao fim do seu TTL (que não quer dizer TransistorTransistorLogic, mas sim TimeToLive) ;)

Assim que tenha oportunidade, crio uma thread sobre networking básico, entretanto, aconselho-vos a estudar o modelo OSI...
 
kazuza disse:
Achas que o pacote de 48b vai ficar eternamente "à procura" do IP de destino?
Clicar para expandir...

Com "à procura" queres dizer saltos entre routers. Se o TTL de origem for 10. Ao fim de 10 saltos, morre.

Basicamente fiz as "perguntas" para não ser indelicado e não dizer directamente que tavas a dizer bacuradas, mas já que me mandaste estudar OSI....pronto tens aqui a minha resposta "sincera".

Of course...

Se o teu IP não responder, como saberá o remetente se deve continuar a enviar, ou melhor. se o pacote foi recebido?
Clicar para expandir...

Ups, vai estudar....

Mais, eu até fiz um programa para transferência de dados sobre UDP com confirmação de recepção mas tive de ser EU, ao nivel de aplicação (OSI), a realizar essa mesma operação. Logo, por defeito o UDP não tem "controlo de transferência".

Não percebi muito bem pq raio começaste a meter conceitos de IP (TTL) no meio de uma conversa sobre UDP, mas enfim. Acho que fico por aqui e vou "estudar".
 
AwakE disse:
Basicamente fiz as "perguntas" para não ser indelicado e não dizer directamente que tavas a dizer bacuradas, mas já que me mandaste estudar OSI....pronto tens aqui a minha resposta "sincera".
Clicar para expandir...

Eu estava a dizer bacoradas ;)
Peço desculpa...

aqui estava a falar de TCP, não UDP...

Só te disse para comparares no modelo OSI, porque os dois protocolos funcionam em camadas diferentes (e dá para ter uma melhor perspectiva da coisa)...

Suscintamente, tudo se resume a:

TCP pede ack (acknowledge, e só deois de saber o IP de destino e ter enviado o pacote) , ao passo que UDP não (isto se estivermos a falar de IPs fixos, porque senão, aí a coisa é bem diferente...

Fiquem bem...

Moderar dá tanto trabalho, que uma pessoa até se perde nos pensamentos...
 
Última edição:
kazuza disse:
O TTL,passo a explicar....

Vamos supor que fazes um Ping, a um IP qualquer, que de momento não existe...

Achas que o pacote de 48b vai ficar eternamente "à procura" do IP de destino?

É extinto ao fim do seu TTL (que não quer dizer TransistorTransistorLogic, mas sim TimeToLive) ;)
Clicar para expandir...


Nem pouco mais ou menos...
Nem sequer sei o que o modelo OSI vem para aqui chamado... a inet não usa o modelo osi...

Então vamos por partes...

O que acontece se mandares um ip que de momento não existe...?
Simples, tu mandas o pacote, quando chega ao 1º router é descoberto o próximo salto, e enviado para lá. Quando chega ao último router e tenta enviar esse pacote para aquele que seria o destino, e este não o recebe, por exemplo porque o mac associado a ele não responde, o router envia de volta um pacote ICMP do tipo "destination Unrecheable"

Para que serve o TTL...?

O TTL só serve para uma única situação. As tabelas de routing dos router são dinâmicas e variam com a carga e "agendas" dos vários operadores. Acontece que todos os algoritmos usados para calcular o caminho óptimo entre os routers têm o mau hábito de propagar lentamente as "más notícias" (link que caiu, congestionamento... etc). De forma que é possível que quando um link vai abaixo, um pacote ande eternamente às voltas nos routers à procura desse caminho.
O que acontece é que sempre que um pacote passa por um router, é-lhe decrementado o TTL. Sempre que o TTL chega a 0 o pacote é descartado...
 
"O que acontece se mandares um ip que de momento não existe...?
Simples, tu mandas o pacote, quando chega ao 1º router é descoberto o próximo salto, e enviado para lá. Quando chega ao último router e tenta enviar esse pacote para aquele que seria o destino, e este não o recebe, por exemplo porque o mac associado a ele não responde, o router envia de volta um pacote ICMP do tipo "destination Unrecheable""

Tafinho, noob here, por isso desculpa esta minha duvida...
No meu caso concreto, o ip existe, atraz desse ip estão várias maquinas, cada uma com o seu MAC adress. Até aqui tudo bem.
O pacote enviado vai saltando de router em ruter até chegar ao destino e até chegar ao meu ip e como eu tenho o cablemodem ligado existe um MAC adress independemente de a minha máquina responder ou ñ, certo? E se existe um MAC então do o pacote alcança o destino e ñ retorna erro se usar UDP, certo?
 
NeoToPower disse:
como eu tenho o cablemodem ligado existe um MAC adress independemente de a minha máquina responder ou ñ, certo? E se existe um MAC então do o pacote alcança o destino e ñ retorna erro se usar UDP, certo?
Clicar para expandir...

Pode ou não retornar erro...
Se existe um MAC associado ao IP, em princípio não vai retornar nenhum ICMP.
MAS, estamos a falar de windoze...

Nesse caso o (e sem contar com a FW) o windoze devolve um pacote RST para a origem, isto de em TCP e se o porto estiver fechado.

Com a firewall podem acontecer inúmeras coisas, tipicamente nem responde nem dá erro.
 
Tafinho disse:
Não não é...

É mantido estado tanto no servidor como no cliente.
Senão como mantens o seq number e o last ack ...?
Clicar para expandir...


Não mantém! Vem no header do pacote...

O modelo OSI serviu só para destinguir os 2 protocolos: TCP e UDP

Quanto à minha resposta inicial ,como já tinha dito, foi um lapso da minha parte ...
 
kazuza disse:
Não mantém! Vem no header do pacote...
Clicar para expandir...

Ai maezinha... onde isto já vai...

Olha lá o termo "receive window" não te diz nada...?
Nunca te perguntaste a ti próprio qual a vantagem do TCP...?

Então é assim, o TCP serve principalmente para garantir a entrega dos pacotes...

Então imaginemos uma comunicação...

Um pc envia um syn para outro.
Este responde com syn ack

O pc envia um ack com a sua janela e começa a enviar os pacotes até encher a janela...

Ora, segundo aquilo que tu dizes, os pacotes assim que enviados podem ser apagados da memória, bem, nesse caso nem sequer pode existir janela, mas suponhamos que sim...

Agora imaginemos que o 2º pc recebe todos os pacotes menos o do meio... e como tal envia o ACK de todos os pacotes (ou só do último, é opcional)...

Como o 1º PC não manteve o estado, não sabe que pacotes já recebeu o ACK ou os que não recebeu, mas mais grave, pode até saber que não recebeu o ACK de um pacote, mas como não guardou estado, volta a enviar todos até lá, errado! Como não mantem estado também não os guardou... enfim, isto não tem pés nem cabeça...

É óbvio que o TCP mantém estado tanto no servidor como no cliente.
É precisamente por esta razão que o UDP é usado no DNS...
 
Tens razão!
Fica no buffer

Há dias que não se dá uma para a caixa...

Hoje é um deles... ;)

Obrigado pela correcção!

Fiquei confuso por ter visto algures alguém aplicar esse termo...

TILT!
 
confirmo tudo o que o tafinho disse! ou nao tivesse feito ontem um exame de introducao as redes de telecomunicacoes;) a principal vantagem do tcp é que garante a entrega de todos os segmentos! e tem varios mecaninsmos de prevencao de congestao da rede...

O udp é usado no DNS,penso que principalmente devido a uma questao de "tempo"... é mt mais rapido,porque nao resolve a congestao,nem tem tempo de iniciacao da sessao...E se houver alguma perda,nao ha prob que o DNS é actualizado rapidamente.
e afinal..www significa world wide wait :P
_zZz_
 
_zZz_ disse:
O udp é usado no DNS,penso que principalmente devido a uma questao de "tempo"... é mt mais rapido,porque nao resolve a congestao...E se houver alguma perda,nao ha prob que o DNS é actualizado rapidamente.
e afinal..www significa world wide wait :P
_zZz_
Clicar para expandir...



BROADCAST, anyone? ;)
 
_zZz_ disse:
confirmo tudo o que o tafinho disse! ou nao tivesse feito ontem um exame de introducao as redes de telecomunicacoes;)
Clicar para expandir...

Depois de ter o RFC de uma ponta à outra um gajo fica a saber umas coisinhas...
mas valeu a pena, 2 semanas de investigação, 2 tardes de trabalho, 20 ;)

Qualquer dia tenho de fazer o site sobre o trabalho, mas só depois de o apresentar em congresso.... é pena já não dar este ano, enfim, fica para o próximo.
 
Tafinho disse:
Depois de ter o RFC de uma ponta à outra um gajo fica a saber umas coisinhas...
mas valeu a pena, 2 semanas de investigação, 2 tardes de trabalho, 20 ;)

Qualquer dia tenho de fazer o site sobre o trabalho, mas só depois de o apresentar em congresso.... é pena já não dar este ano, enfim, fica para o próximo.
Clicar para expandir...
RFC OU TFC? rfc nao sei o k sera..

se for tfc,conta la pormenores acerca disso:)

um abraco
_zZz_
 
_zZz_ disse:
RFC OU TFC? rfc nao sei o k sera..

se for tfc,conta la pormenores acerca disso:)

um abraco
_zZz_
Clicar para expandir...

TFC - Trabalho de Final de Curso
RFC - Request For Comment , na realidade são os documentos do IETF que descrevem os standarts da Internet, muito má leitura, pois são escritos por engenheiros, e não têm qq tipo de palha.

Aquele trabalho não é um TFC, mas teve para ser, só que fui preguiçoso... assim vou ter de fazer a parte que era para TFC à mesma... enfim...


O meu TFC é uma coisa mais útil, mas bastante diferente. Quando tiver acabado dou notícias. :cool:
 
Pois deve ser. Como às vezes "discordamos" tava a ver que ainda eramos colegas de curso, que eu também tou a fazer TFC mas em LEEC.

Eu falei um UDP, porque assim conseguiamos fazer um programa em que o receptor nunca faria ligações para o remetente (solicitação por telefone :D ), logo havia uma maneira de dar a volta a teoria de contar o trafego "solicitado". Limitava o tipo de serviço mas....
 
AwakE disse:
Pois deve ser. Como às vezes "discordamos" tava a ver que ainda eramos colegas de curso, que eu também tou a fazer TFC mas em LEEC.

Eu falei um UDP, porque assim conseguiamos fazer um programa em que o receptor nunca faria ligações para o remetente (solicitação por telefone :D ), logo havia uma maneira de dar a volta a teoria de contar o trafego "solicitado". Limitava o tipo de serviço mas....
Clicar para expandir...
humm...essa era uma boa ideia... tipo um servidor baseado em UDP... Pena que o trb final deste semestre tenha sido um servidor http baseado em TCP :(

mas nao sei se isso funcionara bem assim..Afinal,pelo menos na netvisao se for tudo lido pelo contador interno do modem (é assim que eles dizem k fazem..) ele contaria na mesma como um download.Agora a questao do nao solicitado é que é caricata...
Nenhum de voces conhece algum "servidor" implementado por UDP? pelo msn faziamos uns testes :P

_zZz_
 
Aquele trabalho que eu disse que fiz sobre UDP foi para essa cadeira. Quando eu fiz nós tinhamos 2 trabalhos, um servidor HTTP de paginas web com CGI, e transmissão fiavel por UDP. Acho que fiz ha 2 anos, já não me lembro.

Sim, em relação ao contador do modem (ou na Netcabo) não interessa se é UDP ou não. Algumas pessoas levantaram foi o problema da ilegalidade da netcabo contar trafego não solicitado. Só quis mostrar que se adoptassem por essa solução de so contar o trafego "solicitado" (o que em termos de engenharia seria um desafio tremendo) mesmo assim seria possivel dar a volta a situação.
 
Inicie sessão ou registe-se para poder participar.
Back
Topo