计算机网络大作业

  • 格式:doc
  • 大小:74.50 KB
  • 文档页数:9

下载文档原格式

  / 9
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

《计算机网络》大作业题目:设计实现一个GBN协议

院系:计算机学院

班级:计算机科学与技术系6班

班号:0703106

学号:1070310611

姓名:娄志云

UDP协议的特点

1、UDP传送数据前并不与对方建立连接,即UDP是无连接的,在传输数据前,发送方和接收方相互交换信息使双方同步。

2、UDP不对收到的数据进行排序,在UDP报文的首部中并没有关于数据顺序的信息(如TCP 所采用的序号),而且报文不一定按顺序到达的,所以接收端无从排起。

3、UDP对接收到的数据报不发送确认信号,发送端不知道数据是否被正确接收,也不会重发数据。

4、UDP传送数据较TCP快速,系统开销也少。

5、由于缺乏拥塞控制(congestion control),需要基于网络的机制来减小因失控和高速UDP 流量负荷而导致的拥塞崩溃效应。换句话说,因为UDP发送者不能够检测拥塞,所以像使用包队列和丢弃技术的路由器这样的网络基本设备往往就成为降低UDP过大通信量的有效工具。数据报拥塞控制协议(DCCP)设计成通过在诸如流媒体类型的高速率UDP流中增加主机拥塞控制来减小这个潜在的问题。

从以上特点可知,UDP提供的是无连接的、不可靠的数据传送方式,是一种尽力而为的数据交付服务。

滑动窗口技术

只有在接收窗口向前滑动时(与此同时也发送了确认),发送窗口才有可能向前滑动。

收发两端的窗口按照以上规律不断地向前滑动,因此这种协议又称为滑动窗口协议。

当发送窗口和接收窗口的大小都等于1时,就是停止等待协议。

当发送窗口大于1,接收窗口等于1时,就是回退N步协议。

当发送窗口和接收窗口的大小均大于1时,就是选择重发协议。

协议中规定,对于窗口内未经确认的分组需要重传。这种分组的数量最多可以等于发送窗口的大小,即滑动窗口的大小n减去1(因为发送窗口不可能大于(n-1),起码接收窗口要大于等于1)。

TCP协议采用滑动窗口协议来解决了端到端的流量控制。

程序设置发送方和接收方使用固定的窗口尺寸,这是在收到确认以前可以发送的最大数据量。

基于TCP协议的滑动窗口工作机制

TCP协议在工作时,如果发送端的TCP协议软件每传输一个数据分组后,必须等待接收端的确认才能够发送下一个分组,由于网络传输的时延,将有大量时间被用于等待确认,导致传输效率低下。为此TCP在进行数据传输时使用了滑动窗口机制。

TCP滑动窗口用来暂存两台计算机问要传送的数据分组。每台运行TCP协议的计算机有两个滑动窗口:一个用于数据发送,另一个用于数据接收。发送数据的滑动

窗口:发送端待发数据分组在缓冲区排队等待送出。被滑动窗口框入的分组,是可以在未收到接收确认的情况下最多送出的部分。滑动窗口左端分组,是已经被接收端确认收到的分组。随着新的确认到来,窗口不断向右滑动。

TCP协议软件依靠滑动窗口机制解决传输效率和流量控制问题。它可以在收到确认信息之前发送多个数据分组。这种机制使得网络通信处于忙碌状态,提高了整个网络的吞吐率,它还解决了端到端的通信流量控制问题,允许接收端在拥有容纳足够数据的缓冲之前对传输进行限制。在实际运行中,TCP滑动窗口的大小是可以随时调整的。收发端TCP协议软件在进行分组确认通信时,还交换滑动窗口控制信息,使得双方滑动窗口大小可以根据需要动态变化,达到在提高数据传输效率的同时,防止拥塞的发生。

UDP滑动窗口协议的设计与实现

UDP滑动窗口协议是建立在UDP上的应用层协议之上的。传输层使用的仍是UDP,但在应用层使用滑动窗口技术,并通过模拟TCP的一些机制以保证UDP的低协议处理开销和获得高通信可靠性。

在开始传输前,不进行tcp的3次握手。

在开始传输的过程中,发送方向接收方发送分组。此时,模拟tcp的可靠信息传输的机制,采用确认报文来对已接受的分组进行确认。如果受到确认报文,则窗口向右移动;如果没受到确认报文,则等待确认报文,超过设定的时间则重新传输未确认的分组。演示过程由手动控制kill哪个报文段。如果kill其中的一个报文,则同一窗口的后续分组的确认报文不进行发送,等待设定时间到,进行重传分组数据。重新进行报文的确认。此窗口的数据发送完毕后,窗口向右移动。

采用JAVA的图形化界面模拟gbn协议程序设计

设定个窗口的大小

final int window_len_def = 8;

final int pack_width_def = 10;

final int pack_height_def = 30;

final int h_offset_def = 100;

final int v_offset_def = 50;

final int v_clearance_def = 300;

final int total_packet_def = 20;

final int time_out_sec_def = 30;

对不同的图形进行定义

final Color unack_color = Color.red;

获取packet_width参数值到strPackWd

strWinLen = getParameter("window_length");

发生异常执行catch (Exception e)

try {

if (strWinLen != null) window_len = Integer.parseInt(strWinLen);

} catch (Exception e) {}

上面调用getParameter发生错误的时候没有返回值时采用下面的定义的默认值

window_len = (window_len > 0) ? window_len : window_len_def;

pack_width = (pack_width > 0) ? pack_width : pack_width_def;

下面开始定义图形化界面的按键

send = new Button("Send New");

创建主线程,开始线程

public void start()

{

if (gbnThread==null)

gbnThread = new Thread(this);

gbnThread.start();

检查分组数据包是否在传输,如果开始传输则发送从0到total_packet的数据包

if (onTheWay(sender))

{

for (int i=0; i

if (sender[i]!= null)

if (sender[i].on_way)

if (sender[i].packet_pos < (v_clearance-pack_height))

sender[i].packet_pos+=5;

如果分组包正在传输到目的地,收到分组包后,接收方返回一个acknowledgement确认报文通知发送方此分组已收到

else if (sender[i].packet_ack)

{

sender[i].reached_dest = true;

if (check_upto_n(i))

{ // packets are received.

sender[i].packet_pos = pack_height+5;

sender[i].packet_ack = false;

正确接收,窗口向右移动

statusMsg = "Packet "+i+" received. Acknowledge sent.";

如果传送失败,没有返回确认报文,则不返回确认报文

sender[i].on_way = false;

statusMsg = "Packet "+i+" received. No acknowledge sent.";

一下为图形化操作的定义

Send按下的时候