• Aucun résultat trouvé

4. PRACTICAL STEPS TO MINIMIZE RISK

4.5. At the level of the individual

Nesse estudo de caso foram relacionados alguns requisitos a partir da especificação do protocolo TCP (protocolo alvo) para serem utilizados na aplicação da metodologia de testes de conformidade. Os requisitos alvo estabelecidos a partir das especificações do protocolo TCP para esse estudo de caso são apresentados a seguir:

1. Estabelecimento de conexões TCP; 2. Transferência de dados;

3. Multiplexação e demultiplexação de processos de aplicação; 4. Controle de fluxo;

5. Controle de congestionamento; 6. Encerramento de conexões TCP.

Descrição dos requisitos/funcionalidades do sistema a ser testado Definição da especificação dos testes e

dos propósitos de testes Desenvolvimento dos casos de teste correspondentes aos propósitos de testes

Implementação e execução dos casos de teste

Análise dos resultados obtidos

1

2

3

4

50

Alguns testes selecionados nesta dissertação não são relevantes para determinar que um modelo de simulação não apresentará comportamento adequado para experimentos (TC_TCP_2, TC_TCP_3 e TC_TCP_6) em relação às especificações, entretanto, são utilizados neste estudo de caso para validar a metodologia empregada.

Para cada requisito será elaborado um ou mais propósitos de teste. Esses propósitos relacionam as condições a serem observadas para a execução dos testes. Para facilitar o entendimento da seqüência das mensagens trocadas pelos agentes foram utilizadas ilustrações MSC (Message Sequence Chart) para cada propósito de teste. O propósito de teste TP_TCP_001 descreve um teste referente ao requisito 1.

4.2.1.1 Propósito de teste TP_TCP_001

Identificador TP_TCP_001 Referência Requisito 1

Condições

iniciais Duas máquinas (cliente e servidor) conectadas através de serviços da camada de rede. Os estados das máquinas são CLOSED e a LISTEN para cliente e

servidor, respectivamente.

Controle a ser executado

O cliente envia uma mensagem (segmento SYN) ao servidor e passa ao estado SYN-SENT, permanecendo neste até receber o reconhecimento dessa

mensagem (segmento SYN ACK) . O servidor (que inicialmente encontra-se no estado LISTEN) passa ao estado SYN-RECEIVED e envia um segmento de reconhecimento (segmento SYN ACK) ao cliente. Ao receber o segmento SYN ACK, o cliente passa ao estado ESTABLISHED e envia um segmento de reconhecimento ao servidor. O servidor, ao receber o reconhecimento, passa ao estado ESTABLISHED.

Critério para conclusão

O estabelecimento da conexão foi realizado com sucesso. A Figura 4.6 ilustra o propósito de teste TP_TCP_001.

Figura 4.6 MSC TP_TCP_001 C l i e n t e C L O S E D S Y N S Y N - S E N T A C K E S T A B L I S H E D S e r v i d o r L I S T E N S Y N A C K S Y N - R E C E I V E D E S T A B L I S H E D n u m s e q = 0 n u m s e q = 1 0 0 , a c k = 1 a c k = 1 0 1

51

O propósito de teste TP_TCP_002 descreve um teste referente ao requisito 2, visando verificar se a seqüência dos segmentos é realizada corretamente.

4.2.1.2 Propósito de teste TP_TCP_002

Identificador TP_TCP_002 Referência Requisito 2

Condições

iniciais Duas máquinas (remetente e destinatário) conectadas através de serviços da camada de rede. Os estados das máquinas são ESTABLISHED.

Controle a ser executado

O remetente envia grande quantidade de dados para o destinatário. O primeiro segmento tem o campo numero_sequencia = 100 e possui 536 bytes de dados (MSS). Os segmentos posteriores têm a mesma quantidade de dados (MSS) e devem ter o campo numero_sequencia = numero_sequencia do último segmento enviado + “valor do tamanho do campo de dados” desse segmento.

Para cada segmento recebido pelo destinatário, este deverá enviar um segmento de reconhecimento cujo campo ack = número_sequencia do segmento recebido + 1.

Critério para

conclusão A transferência de dados foi realizada satisfatoriamente, mantendo a sequência correta dos dados.

A Figura 4.7 ilustra o propósito de teste TP_TCP_002.

Figura 4.7 MSC TP_TCP_002

O propósito de teste TP_TCP_003 descreve um teste referente ao requisito 2, cujo objetivo é verificar se o FullTCP utiliza como tamanho máximo dos segmentos o valor da variável MSS. Cliente ESTABLISHED TCP TCP Servidor ESTABLISHED ACK A CK

num seq = 1, tam = 536

ack = 537

num seq = 537, tam = 536

52

4.2.1.3 Propósito de teste TP_TCP_003

Identificador TP_TCP_003 Referência Requisito 2

Condições

iniciais Duas máquinas (remetente e destinatário) conectadas através de serviços da camada de rede. Os estados das máquinas são ESTABLISHED.

Controle a ser

executado O remetente envia grande quantidade de dados (maior que o MSS, mas não múltiplo deste) para o destinatário. O primeiro segmento tem o campo

numero_sequencia =1 e possui 536 bytes de dados (MSS). Os segmentos posteriores têm a mesma quantidade de dados (MSS) e devem ter o campo número_sequencia = numero_sequencia do último segmento enviado + “valor do tamanho do campo de dados” desse segmento, exceto o segmento final que obviamente deve conter o restante dos dados a ser transmitido.

Critério para

conclusão O TCP constrói segmentos utilizando o tamanho máximo permitido (MSS - Maximum Segment Size) como valor limite.

A Figura 4.8 ilustra o propósito de teste TP_TCP_003.

Figura 4.8 MSC TP_TCP_003

O propósito de teste TP_TCP_004 descreve um teste referente ao requisito 2, cujo objetivo é verificar a utilização de um temporizador para controlar a retransmissão em caso de perda de segmentos. Cliente ESTABLISHED TCP TCP TCP Servidor ACK ACK ACK

num seq = 1, tam = 536 ack = 537

num seq = 537, tam = 536

num seq = 1073, tam = 428 ack = 1073

ack = 1501

53

4.2.1.4 Propósito de teste TP_TCP_004

Identificador TP_TCP_004 Referência Requisito 2

Condições

iniciais Duas máquinas (remetente e destinatário), com estados ESTABLISHED, estão conectadas através de serviços da camada de rede, que também transporta tráfego

de retaguarda.

Controle a ser executado

O remetente envia dados para o destinatário. No envio, alguns segmentos podem sofrer grande atraso ou até mesmo podem ser descartados devido ao

congestionamento gerado pelo tráfego de retaguarda. Para tratar esse caso, um temporizador deve ser iniciado e, se não receber o reconhecimento do segmento ao final de um determinado período de tempo, o remetente deve reenviar o segmento.

Critério para

conclusão O TCP controla um temporizador que determinará o momento de retransmissão de segmentos atrasados ou perdidos na rede.

A Figura 4.9 ilustra o propósito de teste TP_TCP_004.

Figura 4.9 MSC TP_TCP_004

O propósito de teste TP_TCP_005 descreve um teste referente ao requisito 2, cujo objetivo é verificar se o FullTCP identifica perdas de segmentos através do recebimento de acks duplicados. Cliente ESTABLISHED TCP TCP Servidor ESTABLISHED

num seq = 1069, tam = 536

Retrans.

54

4.2.1.5 Propósito de teste TP_TCP_005

Identificador TP_TCP_005 Referência Requisito 2

Condições

iniciais Duas máquinas (remetente e destinatário), com estados ESTABLISHED, estão conectadas através de serviços da camada de rede, que também transportam

tráfego de retaguarda.

Controle a ser executado

O cliente (remetente) envia dados para o servidor (destinatário). Alguns

segmentos são descartados na rede e não chegam ao destinatário. Este identifica essa lacuna e envia novamente um segmento de reconhecimento referente ao último segmento recebido na sequência correta. Ao receber o terceiro

reconhecimento duplicado para o mesmo segmento, o remetente deve considerar que este foi descartado e reenviá-lo ao destinatário.

Critério para

conclusão O TCP identifica perdas de segmentos através do uso de segmentos de reconhecimento duplicados.

A Figura 4.10 ilustra o propósito de teste TP_TCP_005.

Figura 4.10 MSC TP_TCP_005

O propósito de teste TP_TCP_006 descreve um teste referente ao requisito 3, cujo objetivo é verificar se o FullTCP implementado no ns admite multiplexação de processos das camadas superiores. Cliente ESTABLISHED TCP TCP TCP Servidor ESTABLISHED ACK ACK ACK

num seq = 4289, tam = 536

num seq = 4825, tam = 536

num seq = 5361, tam = 536 ack = 3217

ack = 3217

ack = 3217 TCP

55

4.2.1.6 Propósito de teste TP_TCP_006

Identificador TP_TCP_006 Referência Requisito 3

Condições

iniciais Três máquinas (dois clientes e um servidor) conectadas através de serviços da camada de rede.

Controle a ser

executado O servidor estabelece simultaneamente uma conexão com cada cliente, distinguindo essas conexões através dos campos porta origem e porta destino e dos

endereços de rede (IP).

Critério para

conclusão O TCP realiza multiplexação de processos de aplicação.

A Figura 4.11 ilustra o propósito de teste TP_TCP_006.

Figura 4.11 MSC TP_TCP_006

O propósito de teste TP_TCP_007 descreve um teste referente ao requisito 4 cujo objetivo é verificar se a implementação FullTCP realiza controle de fluxo baseado no campo janela de recepção. Cliente 1 CLOSED SYN SYN-SENT ACK ESTABLISHED Servidor LISTEN 1 LISTEN 2 SYN ACK SYN - RCVED 1 ESTABLISHED 1 SYN ACK SYN - RCVED 2 ESTABLISHED 2 Cliente 2 CLOSED SYN SYN - SENT ACK ESTABLISHED num seq = 0

num seq = 100, ack = 1

num seq = 0 ack = 101

num seq = 300, ack = 1

56

4.2.1.7 Propósito de teste TP_TCP_007

Identificador TP_TCP_007 Referência Requisito 4

Condições

iniciais Duas máquinas (remetente e destinatário) conectadas através de serviços da camada de rede. Os estados das máquinas são ESTABLISHED.

Controle a ser

executado Durante toda a conexão (incluindo seu estabelecimento), o destinatário informa ao remetente, através do campo janela de recepção, o espaço disponível para receber

novos segmentos. O remetente deve utilizar essa informação para limitar o fluxo de transmissão à capacidade de recepção do destinatário.

Critério para

conclusão O TCP realiza controle de fluxo baseado no campo janela de recepção.

A Figura 4.12 ilustra o propósito de teste TP_TCP_007.

Figura 4.12 MSC TP_TCP_007

O propósito de teste TP_TCP_008 descreve um teste referente ao requisito 5, cujo objetivo é verificar se a implementação do FullTCP utiliza a variável janela de congestionamento (CWND) para realizar controle de congestionamento através do uso do algoritmo slow start.

Cliente ESTABLISHED TCP TCP TCP TCP TCP TCP TCP TCP TCP Servidor ESTABLISHED ACK ACK ACK ACK ACK num seq = 4289, tam = 536

num seq = 4825, tam = 536

num seq = 5361, tam = 536

num seq = 5897, tam = 536

num seq = 6433, tam = 536

num seq = 6969, tam = 536

num seq = 7505, tam = 536

num seq = 8041, tam = 536

num seq = 8577, tam = 344 ack = 4825, jan recep = 4096

ack = 6969, jan recep = 1952

ack = 8577, jan recep = 344

ack = 8921, jan recep = 0

57

4.2.1.8 Propósito de teste TP_TCP_008

Identificador TP_TCP_008 Referência Requisito 5

Condições iniciais

Duas máquinas (remetente e destinatário) conectadas através de serviços da camada de rede. Os estados das máquinas são ESTABLISHED.

Janela de recepção é sempre maior que a janela de congestionamento. Janela de congestionamento (CWND) = Número de bytes de um MSS. Slow Start Threshold (Limiar) inicial é definido em 64 KB.

Controle a ser

executado O remetente envia dados de acordo com uma janela de congestionamento. No envio dos segmentos um temporizador é iniciado. A cada segmento reconhecido

antes que o temporizador expire, a janela é incrementada de um MSS. Este procedimento se repete até que a janela de congestionamento alcance o valor do limiar.

Critério para

conclusão O TCP realiza controle de congestionamento baseado na variável janela de congestionamento e no algoritmo slow start.

A Figura 4.13 ilustra o propósito de teste TP_TCP_008.

Figura 4.13 MSC TP_TCP_008 Cliente ESTABLISHED janela = 536 (1 segmento) TCP janela = 1072 (2 segmentos) TCP TCP janela = 1608 (3 segmentos) janela = 2144 (4 segmentos) TCP TCP TCP janela = 2680 (5 segmentos) janela = 3216 (6 segmentos) janela = 3752 (7 segmentos) Servidor ESTABLISHED ACK ACK ACK ACK ACK ACK num seq = 1, tam = 536

num seq = 537, tam = 536 num seq = 1073, tam = 536

num seq = 1609, tam = 536 num seq = 2145, tam = 536 num seq = 2681, tam = 536

ack = 2681 ack = 3217 ack = 1609 ack = 1073 ack = 2145 ack = 537

58

O propósito de teste TP_TCP_009 descreve um teste referente ao requisito 5, cujo objetivo é verificar se a implementação do FullTCP utiliza a variável janela de congestionamento (CWND) para realizar controle de congestionamento através do uso do algoritmo congestion avoidance.

4.2.1.9 Propósito de teste TP_TCP_009

Identificador TP_TCP_009 Referência Requisito 5

Condições iniciais

Duas máquinas (remetente e destinatário) conectadas através de serviços da camada de rede. Os estados das máquinas são ESTABLISHED.

Janela de recepção é sempre maior que a janela de congestionamento. Janela de congestionamento (CWND) = Threshold (Limiar).

Controle a ser executado

O remetente envia dados de acordo com uma janela de congestionamento. No envio dos segmentos um temporizador é iniciado. A partir do instante em que a janela de congestionamento atinge o limiar, essa janela deve ser incrementada no valor da quantidade de bytes de um MSS quando todos os segmentos enviados forem reconhecidos. Esse comportamento deve ser repetido até que aconteça um estouro do período de tempo controlado pelo temporizador. Quando esse

estouro acontecer, o valor do limiar deve ser reduzido à metade da janela de congestionamento.

Critério para conclusão

O TCP realiza controle de congestionamento baseado na variável janela de congestionamento e no algoritmo congestion avoidance.

A Figura 4.14 ilustra o propósito de teste TP_TCP_009.

Figura 4.14 MSC TP_TCP_009

O propósito de teste TP_TCP_010 descreve um teste referente ao requisito 6, cujo objetivo é verificar se a implementação do FullTCP realiza a finalização das conexões ativas.

Cliente ESTABLISHED janela = 65928 (123 segmentos) TCP janela = 65932 (123,0081 segmentos) TCP TCP Servidor ESTABLISHED ACK

num seq = 65929, tam = 536

num seq = 66465, tam = 536

num seq = 67001, tam = 536 ack = 65929

59

4.2.1.10 Propósito de teste TP_TCP_010

Identificador TP_TCP_010 Referência Requisito 6

Condições

iniciais Duas máquinas (remetente e destinatário) conectadas através de serviços da camada de rede. Os estados das máquinas são ESTABLISHED.

Controle a ser

executado Uma das máquinas (o remetente, por exemplo) deseja encerrar a conexão. O remetente inicia o processo enviando um segmento com o campo FIN setado

para 1 e passa ao estado FIN_WAIT_1. O destinatário passa ao estado CLOSE_WAIT e envia um segmento de reconhecimento. Ao receber o reconhecimento, o remetente passa ao estado FIN_WAIT_2 e aguarda a solicitação da outra parte para encerrar a conexão. O destinatário envia o segmento com o campo FIN setado para 1 e passa ao estado LAST_ACK. O remetente recebe o segmento, passa ao estado TIME_WAIT e envia o reconhecimento ao destinatário. Após aguardar um período de tempo, o remetente muda o seu estado para CLOSED. O destinatário, ao receber o reconhecimento, passa ao estado CLOSED.

Critério para

conclusão O encerramento da conexão foi realizado com sucesso.

A Figura 4.15 ilustra o propósito de teste TP_TCP_010.

Figura 4.15 MSC TP_TCP_010

4.2.2 Derivação, implementação e mapeamento dos casos de teste

Nesta seção serão descritos os cenários desenvolvidos no ns com seus respectivos casos de teste. Para a realização dos testes de conformidade, cada caso de teste foi mapeado em um cenário no ns. Os casos de teste para este estudo de caso foram implementados em TTCN na forma

Cliente ESTABLISHED FIN FIN-WAIT-1 FIN-WAIT-2 TIME -WAIT ACK TIME WAIT CLOSED Servidor ESTABLISHED CLOSE - WAIT ACK FIN LAST- ACK CLOSED

60

tabular e foram baseados nos propósitos de teste descritos na Seção 4.2.1. Os cenários são escritos em OTcl, linguagem utilizada pelo ns para a geração de cenários de simulação. A Tabela 4.1 descreve um caso de teste relativo ao propósito de teste TP_TCP_001.

Tabela 4.1 Caso de teste TC_TCP001

Para o primeiro caso de teste (Tabela 4.1), que verifica o estabelecimento da conexão TCP, foi utilizado o seguinte cenário: dois nós (n0 e n1) conectados diretamente através de um link de 1MB, com atraso de 50ms. Há um agente FullTCP/Tahoe anexado a cada nó e uma fonte FTP transmite dados do n0 para o n1. Foram realizadas 100 conexões consecutivas, a fim de observar se a conexão anterior influenciava de alguma forma na próxima conexão.

O segundo caso de teste avalia a ordenação dos segmentos, isto é, observa se o campo número de sequência está recebendo os valores corretos, sendo incrementado com o valor do tamanho do campo de dados do segmento. A Tabela 4.2 descreve o caso de teste relativo ao propósito de teste TP_TCP_002.

Tabela 4.2 Caso de teste TC_TCP002

A topologia do TC_TCP_001 foi utilizada para este caso de teste (isto é, dois nós conectados diretamente através de um link de 1Mb, com atraso de 50ms, com agentes FullTCP/Tahoe anexados). Nesse caso, a fonte FTP transmite dados do n0 para o n1 durante 100 segundos.

Nr Label Verdict Comments

01 num_seq = 0, estado_cliente = SYN_SENT

02 num_seq = 100, ack=1, estado_serv = SYN_RCV

03 (P) ack = 101, estado_cliente = ESTABLISHED, estado_serv = ESTABLISHED Detailed Comments: Cliente ! SYN_PACKET

Neste caso de teste não é considerada a perda de pacotes. Servidor ? SYN_ACK_PACKET

Cliente ! ACK_PACKET Comments

TC_TCP_001 TP_TCP_001

O estado inicial do cliente é CLOSED e o estado inicial do servidor é LISTEN Behaviour Description

Test Case Id: Test Purpose: Configuration:

Nr Label Verdict Comments

01 num_seq = 1, tam=536

02 ack=537

03 num_seq = 537, tam=536

04 (C)

ack=537. Comportamento correto

05 (NC)

06 (NC)

Comments: O estado inicial do cliente e do servidor é ESTABLISHED. A conexão também transporta

tráfego de retaguarda. ? TIME_OUT ? TIME_OUT Behaviour Description Detailed Comments: Cliente ! TCP_PACKET Servidor ? ACK_PACKET Cliente ! TCP_PACKET Servidor ?ACK_PACKET Test Case Test Case Id:

Test Purpose: Configuration:

TC_TCP_002 TP_TCP_002

61

O TC_TCP_003 (Tabela 4.3) tem como objetivo verificar se os dados estão sendo distribuídos corretamente nos segmentos, de acordo com o tamanho do segmento (536 bytes nesse caso) e a quantidade total de dados a ser enviada. Ainda é utilizada a mesma topologia do TC_TCP_001, na qual o n0 transmite 1500 bytes de dados para o n1. Considerando que 1500 não é múltiplo de 536, o último segmento deve conter menos de 536 bytes. A Tabela 4.3 descreve um caso de teste relativo ao propósito de teste TP_TCP_003.

Tabela 4.3 Caso de teste TC_TCP003

No quarto caso de teste (Tabela 4.4), que avalia a implementação do temporizador de retransmissão, novos nós são adicionados à topologia. Entre os nós n0 e n1 são inseridos dois nós n2 e n3, formando a sequência n0 - n2 - n3 - n1. Todos os links apresentam capacidade de 1Mb e a soma total do atraso nos links é de 50ms. O n0 transmite dados para n1 durante 100 segundos. Nesse mesmo período de tempo é gerado, entre os nós n2 e n3, um tráfego de retaguarda (background) que preenche praticamente todo o link, utilizando uma fonte CBR (Constante Bit Rate) que transmite a uma taxa de 1024Kb. O objetivo deste tráfego é gerar congestionamento e consequentemente perda de segmentos TCP. A Tabela 4.4 descreve um caso de teste relativo ao propósito de teste TP_TCP_004.

Tabela 4.4 Caso de teste TC_TCP004

O TC_TCP_005 (Tabela 4.5) utiliza exatamente o mesmo cenário do caso de teste

Nr Label Verdict Comments

01 num_seq = 1, tam=536 02 (C) ack=537 03 num_seq = 537, tam=536 04 (C) ack=1073 06 num_seq = 537, tam=428 07 (C) ack=1501 08 (NC) ack <> 1501 09 (NC) ack <> 1073 10 (NC) ack=537 Servidor ? ACK_PACKET Cliente ! TCP_PACKET Servidor ?ACK_PACKET Cliente ! TCP_PACKET Servidor ? ACK_PACKET Servidor ? ACK_PACKET Behaviour Description Cliente ! TCP_PACKET Test Case Test Case Id:

Test Purpose: Configuration:

Verificar o uso de MSS para o tamanho dos segmentos Servidor ? ACK_PACKET

Comments

TC_TCP_003 TP_TCP_003

O estado inicial do cliente e do servidor é ESTABLISHED.

Servidor ? ACK_PACKET Detailed Comments:

Nr Label Verdict Comments

01 num_seq = 1069, tam=536

02

03 (C) num_seq = 1069, tam=536

04 (NC) num_seq <> 1069

O estado inicial do cliente e do servidor é ESTABLISHED. A conexão também transporta tráfego de retaguarda.

Comments

Behaviour Description Test Case Test Case Id:

Test Purpose: Configuration: TC_TCP_004 TP_TCP_004 Detailed Comments: Cliente ! TCP_PACKET ? TIME_OUT Cliente ! TCP_PACKET Cliente ! TCP_PACKET

62

anterior (TC_TCP_004). Contudo, neste caso de teste o objetivo é verificar o envio, o recebimento e o tratamento de reconhecimentos duplicados. Em outras palavras, observa-se se, ao receber um segmento fora de sequência, o destinatário (n1) envia reconhecimento duplicado. E se o remetente, ao receber três reconhecimentos duplicados consecutivamente, reenvia o segmento indicado nestes reconhecimentos. A Tabela 4.5 descreve um caso de teste relativo ao propósito de teste TP_TCP_005.

Tabela 4.5 Caso de teste TC_TCP005

Para o sexto caso de teste (Tabela 4.6), que visa testar a multiplexação/demultiplexação de processos de aplicação, é utilizado um cenário com a seguinte topologia: três nós (n0, n1, n2) conectados em sequência (isto é, n0 conecta-se a n1, que está conectado a n2) através de um link de 1MB, com atraso de 50ms (para cada par). Cada nó apresenta um agente FullTCP/Tahoe e os nós n0 e n2 (clientes) tentam estabelecer conexão com n1 (servidor) simultaneamente. A Tabela 4.6 descreve um caso de teste relativo ao propósito de teste TP_TCP_006.

Tabela 4.6 Caso de teste TC_TCP006

Nr Label Verdict Comments

01 num_seq=4289, tam=536 02 (C) ack=3217 03 num_seq=4825, tam=536 04 (C) ack=3217 06 num_seq=5361, tam=536 07 (C) ack=3217 08 num_seq=3217, tam=536 09 (NC) num_seq=5897, tam=536 Comments: Cliente ! TCP_PACKET Servidor ? ACK_PACKET

O estado inicial do cliente e do servidor é ESTABLISHED. A conexão também transporta tráfego de retaguarda.

Verificar se no terceiro ack duplicado, o cliente envia o segmento solicitado. Cliente ! TCP_PACKET Detailed Comments: Cliente ! TCP_PACKET Servidor ? ACK_PACKET Cliente ! TCP_PACKET Servidor ?ACK_PACKET Behaviour Description Cliente ! TCP_PACKET Test Case Test Case Id:

Test Purpose: Configuration:

TC_TCP_005 TP_TCP_005

Nr Label Verdict Comments

01 num_seq=0. Estado_CL1=SYN_SENT 02 num_seq=100,ack=1. Estado_SV=SYN_RCVED_1 03 num_seq=0. Estado_CL2=SYN_SENT 04 ack=101. Estado_CL1 = SV = ESTABLISHED 06 num_seq=300,ack=1. Estado_SV=SYN_RCVED_2 07 (C) ack=101. Estado_CL2 = SV = ESTABLISHED 08 (NC) CL2 não estabeleceu conexão.

SV ? SYN_ACK_PACKET CL2 ! SYN_PACKET CL1 ! ACK_PACKET ? TIME_OUT CL2 ! ACK_PACKET Test Case Test Case Id:

Test Purpose: Configuration:

Verificar se o servidor pode estabelecer conexões simultâneas

Comments

TC_TCP_006 TP_TCP_006

CL1 e CL2 têm estado CLOSED e o SV mantém estado LISTEN.

Detailed Comments:

Behaviour Description

CL1 ! SYN_PACKET

63

No caso de teste TC_TCP_007 (Tabela 4.7), o objetivo consiste em avaliar a implementação do controle de fluxo, observando o tamanho da janela de recepção informada pelo destinatário. O cenário utilizado nesse caso de teste é o mesmo usado no TC_TCP_002 (Tabela 4.2). A Tabela 4.7 descreve um caso de teste relativo ao propósito de teste TP_TCP_007.

Tabela 4.7 Caso de teste TC_TCP007

Documents relatifs