group14_indigo:Putty

A lot of PuTTY’s complexity and features are in the configuration panel. Once you have worked your way through that and started a session, things should be reasonably simple after that. Nevertheless, there are a few more useful features available.

Often in a PuTTY session you will find text on your terminal screen which you want to type in again. Like most other terminal emulators, PuTTY allows you to copy and paste the text rather than having to type it again. Also, copy and paste uses the Windows clipboard, so that you can paste (for example) URLs into a web browser, or paste from a word processor or spreadsheet into your terminal session.

PuTTY keeps track of text that has scrolled up off the top of the terminal. So if something appears on the screen that you want to read, but it scrolls too fast and it’s gone by the time you try to look for it, you can use the scrollbar on the right side of the window to look back up the session history and find it again.

If you click the left mouse button on the icon in the top left corner of PuTTY’s window, or click the right mouse button on the title bar, you will see the standard Windows system menu containing items like Minimise, Move, Size and Close.

If you choose “Event Log” from the system menu, a small window will pop up in which PuTTY logs significant events during the connection. Most of the events in the log will probably take place during session startup, but a few can occur at any point in the session, and one or two occur right at the end.

PuTTY’s system menu provides some shortcut ways to start new sessions:

• Selecting “New Session” will start a completely new instance of PuTTY, and bring up the configuration box as normal.
• Selecting “Duplicate Session” will start a session with precisely the same options as your current one – connecting to the same host using the same protocol, with all the same terminal settings and everything.

If you select “Change Settings” from the system menu, PuTTY will display a cut-down version of its initial configuration box. This allows you to adjust most properties of your current session. You can change the terminal size, the font, the actions of various keypresses, the colours, and so on.

This system menu option provides a convenient way to copy the whole contents of the terminal screen and scrollback to the clipboard in one go.

The “Clear Scrollback” option on the system menu tells PuTTY to discard all the lines of text that have been kept after they scrolled off the top of the screen. This might be useful, for example, if you displayed sensitive information and wanted to make sure nobody could look over your shoulder and see it. (Note that this only prevents a casual user from using the scrollbar to view the information; the text is not guaranteed not to still be in PuTTY’s memory.)

If you find the title bar on a maximised window to be ugly or distracting, you can select Full Screen mode to maximise PuTTY “even more”. When you select this, PuTTY will expand to fill the whole screen and its borders, title bar and scrollbar will disappear.

For some purposes you may find you want to log everything that appears on your screen. You can do this using the “Logging” panel in the configuration box.

If you find that special characters (accented characters, for example) are not being displayed correctly in your PuTTY session, it may be that PuTTY is interpreting the characters sent by the server according to the wrong character set. There are a lot of different character sets available, so it’s entirely possible for this to happen.

The SSH protocol has the ability to securely forward X Window System applications over your encrypted SSH connection, so that you can run an application on the SSH server machine and have it put its windows up on your local machine without sending any X network traffic in the clear.

The SSH protocol has the ability to forward arbitrary network connections over your encrypted SSH connection, to avoid the network traffic being sent in clear. For example, you could use this to connect from your home computer to a POP-3 server on a remote machine without your POP-3 password being visible to network sniffers.

A lot of Internet protocols are composed of commands and responses in plain text. For example, SMTP (the protocol used to transfer e-mail), NNTP (the protocol used to transfer Usenet news), and HTTP (the protocol used to serve Web pages) all consist of commands in readable plain text.

PuTTY can be made to do various things without user intervention by supplying command-line arguments.

To start a connection to a server called host:

putty.exe [-ssh | -telnet | -rlogin | -raw] [user@]host


For telnet sessions, the following alternative syntax is supported (this makes PuTTY suitable for use as a URL handler for telnet URLs in web browsers):

putty.exe telnet://host[:port]/

In order to start an existing saved session called sessionname, use the -load option
putty.exe -load "session name"

If invoked with the -cleanup option, rather than running as normal, PuTTY will remove its registry entries and random seed file from the local machine.
PuTTY and its associated tools support a range of command-line options, most of which are consistent across all the tools. This section lists the available options in all tools. Options which are specific to a particular tool are covered in the chapter about that tool.
The -load option causes PuTTY to load configuration details out of a saved session. If these details include a host name, then this option is all you need to make PuTTY start a session.
To choose which protocol you want to connect with, you can use one of these options:

-ssh selects the SSH protocol.
-telnet selects the Telnet protocol.
-rlogin selects the Rlogin protocol.
-raw selects the raw protocol.

-v: increase verbosity
-l: specify a login name
-L and -R: set up port forwardings
-m: read a remote command or script from a file
-m: read a remote command or script from a file
-pw: specify a password
-A and -a: control agent forwarding
-X and -x: control X11 forwarding
-t and -T: control pseudo-terminal allocation
-C: enable compression
-1 and -2: specify an SSH protocol version
-i: specify an SSH private key
								

			

group14_indigo:ssh

SSH

Public key cryptography

Public key cryptography uses a public key to encrypt data and a private key to decrypt it. The name public key comes from the fact that you can make the encryption key public without compromising the secrecy of the data or the decryption key.

What this means is that it is safe to send your public key (i.e. the contents of the ~/.ssh/id_rsa.pub file) in electronic mail or by other means e.g. to have a system administrator of a remote site install that key into your ~/.ssh/authorized_keys file. For anyone to actually gain access they need the corresponding private key (i.e. the decrypted contents of ~/.ssh/id_rsa) to identify themselves.

To further protect your private key you should enter a passphrase to encrypt the key when it is stored in the filesystem. This will prevent people from using it even if they gain access to your files.

Creating  authentication key

The very first step is to use ssh-keygen to create an authentication key for yourself. In most cases the defaults for this command are what you want.

Always, always, type in a good pass-phrase when prompted for one. It can be multiple words (i.e. spaces are just fine within the phrase), so you could choose a sentence that you can remember. Changing some of the words by misspelling them or by changing some of the letters into digits is highly recommended to increase the strength of your pass phrase.

Here is a sample session, your input is in bold. Note that the pass-phrase is not echoed back as you type it.

  beowulf% ssh-keygen -t rsa
  Generating public/private rsa key pair.
  Enter file in which to save the key (/u/kim/.ssh/id_rsa): [RETURN]
  Enter passphrase (empty for no passphrase): 1amp jumb3d
  Enter same passphrase again: 1amp jumb3d
  Your identification has been saved in /u/kim/.ssh/id_rsa.
  Your public key has been saved in /u/kim/.ssh/id_rsa.pub.
  The key fingerprint is:
  b7:18:ad:3b:0b:50:5c:e1:da:2d:6f:5b:65:82:94:c5 kim@beowulf.gw.com

Changing  pass-phrase

You can change the pass-phrase at any time by using the -p option of ssh-keygen.

  beowulf% ssh-keygen -p
  Enter file in which the key is (/u/kim/.ssh/id_rsa): [RETURN]
  Enter old passphrase: 1amp jumb3d
  Key has comment '/u/kim/.ssh/id_rsa'
  Enter new passphrase (empty for no passphrase): cow 3ats grass
  Enter same passphrase again: cow 3ats grass
  Your identification has been saved with the new passphrase.

The pass-phrases are not echoed as you type them.

Authorizing access

To allow access to a system for a given identity place the public key in your ~/.ssh/authorized_keys file on that system. All keys listed in that file are allowed access.

Usually you will want to authorize access to the local system using the local key (especially in an environment where multiple systems share the same home directory e.g. using NFS). Thus a good start is to copy the public key for your default identity into the ~/.ssh/authorized_keys file.

  beowulf% cd ~/.ssh
  beowulf% cp id_rsa.pub authorized_keys

You could now copy the ~/.ssh/authorized_keys file to other systems to allow access from the local system. One way to copy the file is to use the scp command, like this:

  beowulf% scp -p ~/.ssh/authorized_keys hrothgar:.ssh/
  kim@hrothgar's password: YourPasswordHere
  authorized_keys               100% 1839     1.2MB/s   00:00

As no identities have been authorized yet on the remote system, you will be asked for your regular login password as seen above. It will not be echoed as you type it. The Copying files between systems section has more information about scp.

.

Directory and file permissions

If access to the remote system is still denied you should check the permissions of the following files on it:

• the home directory itself
• the ~/.ssh directory
• the ~/.ssh/authorized_keys file

The permissions should allow writing only by you (the owner). This example shows the most relaxed permissions you could use.

  hrothgar% cd
  hrothgar% ls -ld . .ssh .ssh/authorized_keys
  drwxr-xr-x 36 kim kim 4096 Jul 25 02:24 .
  drwxr-xr-x  2 kim kim  512 Apr 10 02:30 .ssh
  -rw-r--r--  1 kim kim 1674 Apr 10 02:29 .ssh/authorized_keys

To make the remote system allow access you must change the permissions to disallow writing by others than the owner.

  hrothgar% cd
  hrothgar% chmod go-w . .ssh .ssh/authorized_keys

Remember to do this on all the systems you want to have access to.

 

Logging into remote systems

To establish an interactive connection to a remote system you would use either the slogin or the ssh command. The only parameter is the name of the remote system. The pass-phrase is not echoed back to you when you type it.

  beowulf% slogin hrothgar
  Enter passphrase for key '/u/kim/.ssh/id_rsa': 1amp jumb3d
  Last login: Wed Jul 21 00:00:49 2004 from beowulf.gw.com
  [more output from the remote machine]
  hrothgar%

You can avoid the pass-phrase prompts by keeping the authentication keys in memory. You only need to type the pass-phrase when you add a key into memory.

If your account name on the remote system differs from the one on the local system (the system you are connecting from) you can use the -l switch to specify the remote account name.

  beowulf% slogin -l suominen panix.com
  Last login: Sun Jun 13 14:55:17 2004 from beowulf.gw.com
  [more output from the remote machine]
  panix%

You can change the default remote account name by creating a configuration file entry for the host.

Running commands on remote systems

The ssh command can also be used to run commands on remote systems without logging in. The output of the command is displayed and control returns to the local system. Here is an example which will display all the users logged in on the remote system.

  beowulf% ssh hrothgar who
  christos ttyp8    Oct 17 20:42  (milou)
  beowulf%

If you are using the X Window System you can use this capability to start a terminal window to start an interactive session on the remote system.

  beowulf% ssh -n hrothgar xterm &
  [1] 15866

  beowulf%

group 14_indigo:stop and wait

New protocol for stop and wait.

 

In all types of data communication systems, errors may occur. Therefore error

control is necessary for reliable data communication. Error control involves both

error detection and error correction. Previously error detection can be done by

Cyclic Redundancy Check (CRC) codes and error correction can be performed by

retransmitting the corrupted data block popularly known as Automatic Repeat

Request (ARQ). But CRC codes can only detect errors after the entire block of

data has been received and processed. In this work we use a new and “continuous”

technique for error detection namely, Continuous Error Detection (CED). The

“continuous” nature of error detection comes from using arithmetic coding. This

CED technique improves the overall performance of communication systems

because it can detect errors while the data block is being processed. We focus only

on ARQ based transmission systems. We will show have the proposed CED

technique can improve the throughput of ARQ systems by up to 15%.

Keywords: Cyclic redundancy check codes, arithmetic coding, automatic repeat request.

 

 

1 INTRODUCTION

When we talk about any type of data communication system, we concern only on its

reliability. In all types of data communication systems, errors may occur. Error control is the only way out for avoiding this problem. It comes by detecting the error in first step and then correctin g it in another step. For error detection we had CRC codes and for error correction we use to retransmit the corrupted data which is popularly known as ARQ.Although efficient, CRC’s can detect errors only after an entire block of data has been received and

processed. An error detection scheme that is “continuous” can detect errors while the block is

being processed. Thus, it can enhance the overall performance of the communication systems.

In this paper, we use this type of new and continuous method for detecting the errors. The new

method of error detection is based on the arithmetic coder, and allows for an efficient way to detect errors continuously in the bit-stream by investing a controlled amount of redundancy in the arithmetic coding operation. During our research, we became

aware that the idea of continuous error detection based on arithmetic coding had been tackled earlier by Boyd et al. , albeit with little system performance analysis, or exposition of its utility in communication systems. In this paper, we not only undertake a more rigorous analysis of this paradigm, quantifying the underlying tradeoffs involved in the process, but also establish impressive gains in system performance attainable through sophisticated integration of this novel paradigm into popular, powerful transmission scenarios such as ARQ. Upon applying this method of error detection to stop-and-wait ARQ, gains in throughput were achieved over conventional ARQ schemes at all bit error probabilities. Result shows that the throughput

of new stop -and-wait ARQ protocol i.e. with CED is approximately 15% enhanced than the throughput of the conventional stop -and-wait ARQ protocol i.e. with CRC.

The rest of the paper is organized as follows. The basic idea behind the continuous error detection is introduced in Section 2. Section 3 presents an application of CED for ARQ transmission where it provides significant throughput gains over conventional CRC-based schemes. We conclude in Section 4. References are given in Section 5.

2 IDEA BEHIND CED

To understand the error detection scheme, and understanding of how the arithmetic coder works is necessary. We assume that the reader is familiar with arithmetic coding and refer readers that are unfamiliar with arithmetic coding to [2]. Arithmetic coding is a method of data

compression in which data strings are mapped to code strings which represent the probabilities of the corresponding data strings. The method in which this mapping is achieved requires a model which specifies the assumptions that are made about the source data. A simple example of a model is the memoryless model where the current symbol being encoded is independent of the previously encoded symbols. Another simple example is the first-order Markov model, where the current symbol being encoded is dependent only on the previously encoded

symbol. For simplicity, we will examine the memoryless model, keeping in mind that the analysis generalizes to more sophisticated models. Thus, encoding and decoding via the arithmetic coder function by repetitively partitioning subintervals within the unit interval [0, 1) according to the probabilities of the data symbols. The basic idea is simple and consisting of

adding a “forbidden” symbol that is never encoded by the arithmetic coder, but nonetheless occupies a nonzero measure on the set [0, 1), then upon decoding, if an error occurs, this “forbidden” symbol is guaranteed to be decoded due to the loss of synchronization. The amount of time it takes to decode the “forbidden” symbol after the occurrence of an error is inversely related to the amount of redundancy added through introducing the“forbidden” symbol. T his allows for control of the number of bits we suspect need to be retransmitted.

In fact, we can guarantee to a specified accuracy, that errors will be localized to the previous m bits (where m is a function of the amount of redundancy added) upon decoding the “forbidden” symbol. This is useful in an ARQ setting, becau se as soon as the error is detected, we have a statistical assurance as to how many bits need to be retransmitted to ensure that

the bit in error will be retransmitted.

3 APPLICATION OF CED

Simulations were run using a binary symmetric channel at various bit-error probabilities. Several ten kilobit packets were sent at each bit-error probability, and the resulting throughput was calculated. As a measure of performance, we compared our method of ARQ i.e. with CED to the conventional methods of ARQ i.e. with CRC. The conventional methods of ARQ function by dividing the data into packets and then attaching CRC’s [3] to each packet. Upon detection of an error in the conventional ARQ method, a retransmission of the entire block is requested. To simulate a fair comparison for our method versus conventional ARQ methods, we used the optimal packet size for each bit-error probability tested using conventional

ARQ. The optimal packet size was calculated by differentiating the throughput equation for

conventional ARQ (details can be found in [4]) with respect to the packet size, and solving for the packet size which maximizes throughput. The resulting throughputs are shown in Fig. 1. and we see that the new method of ARQ outperforms conventional ARQ

methods at all bit-error probabilities.

4 CONCLUSION

In this paper we have introduced a new method of error detection for common ARQ protocols. We analytically characterized the tradeoff of added redundancy versus error -detection capability and formulated a method for incorporating this new error detection “device” into an ARQ type scenario. We would also like to mention here that CED can be put to good use to improve throughput performance of transport protocols like TCP over heterogeneous networks, where early detection of an error can result in a potentially greater number of retransmits, thereby increasing the probability of successful reception over a fading channel. This is

currently being verified. The goal of this work is to present the benefits that communication systems can derive from using CED for throughput enhancement.

group14_indigo:remote login

//

//

Access Your Personal Computer

In a matter of minutes you can get fast, easy and secure access to remote computers with LogMeIn. Simply install logmeIn pro2 on the computer you want to access to gain remote control of its desktop, files, applications and network resources over the web.

Now you can get anytime, anywhere remote access to your computer that’s easy to try, buy and use.

logmeIn pr0 2 enables you to work via a web browser with a remote computer from virtually anywhere you have an Internet connection, as if you were sitting right in front of it.

• Transfer a file from your remote desktop your laptop
• Print a flight reservation from a remote computer to a local printer
• Show your Mom a photo on your home PC from her house
• Support your Dad’s computer from across the country
• Listen to your home MP3 collection from work

logmein ignition for iphone and ipod touch, a companion tool to LogMeIn Pro² and LogMeIn Free, lets you experience mobility like never before with one-click access to your LogMeIn computers, right from your Apple iPhone or iPod touch.

• Attach a file from your home computer to an email message
• Share vacation photos from your Mac while at lunch with a friend
• Edit documents on your personal PC from your iPod touch

logmeIn ignition provides one-click remote computer access from your desktop, USB drive or U3 flash drive.

• Carry remote access with you from home and the office – instead of files, folders, CDs or other media
• store passwords securely  for fast access to multiple PCs

group14_indigo:stop and wait ARQ

a

this will give a brief description of all the ARQ’s.

Stop and wait (sometimes abbreviated SaW) is the simplest possible ARQ protocol, used to request retransmission of packets in a communications network.

Protocol Operation

The protocol is very easy to understand, and just as simple to implement. A communication pair is made up of a transmitter and a receiver. The transmitter sends a packet across a communications link, then stop and waits for a reply. Positive acknowledgements are sent back along the link by the receiver; negative acknowledgments can be sent back too, but are often assumed after some time out period has expired.

A sample exchange is shown below.

------------------------------------------> Time
(Packet lost) (Retransmission)
------           ------        ------
TX | Data |         | Data |      | Data |
------.          ------.      .------
.  -----         .      .          -----
RX . | Ack |        .      .         | Ack |
. .-----         .      .          -----
. .              .      .
Link              Timeout
propagation           value
delay


All data packets sent by the transmitter take a certain time to reach the receiver. This is related to the length and velocity of the communications link, and is known as the link propagation delay. The receiver replies to the packet once it has been received by sending an ACK; this is also subject to the propagation delay.

When a packet is lost, as the second packet is in this case, the transmitter’s acknowledgement timer expires. It then can assume that either the data or the acknowledgement didn’t arrive, and so retransmits the previous packet.

Efficiency

The stop and wait protocol is clearly not particularly efficient. Even in the ideal case of no loss, most of the time is spent with the link idle, waiting for the other end to reply. When packets require retransmission, efficiency lowers further.

Efficiency can be calculated fairly easily. Let the size of the data we want to send be D bits, and the header (used for addressing or error detection, for example) be H bits long. Also let the corresponding acknowledgment packet be A bits in size. We must also take into account the link parameters, propagation time Ts and bit rate  B bits/s.

The time taken to complete the transaction is the sum of three terms: the time taken to send the packet, the time taken to send the ack, and the two propagation delays inbetween. This gives us t = (D + H)/B + A/B + 2T as the total time. Ideally, the time taken to send D bits of data across a link with bit rate B would be simply D/B. Rearranging these gives a no-retransmission efficiency of:

η = D/(D + H) × 1/(A + 2TB)

The retransmission timer used by the sender has an ideal value for efficiency. Clearly, it must wait at least the maximum time taken for an acknowledgement to be returned: this is the propagation delay for the data packet, plus the time taken to send the acknowledgement, plus the propagation delay for the acknowledgement. Therefore, the stop time must be S ≥ 2T + A/B.

Since header and ACK size are normally kept to a minimum anyway, the equation above shows that efficiency is governed by the 2TB term. This has the effect that increasing link bit rate actually decreases efficiency; more obviously, efficiency also decreases as the link latency increases. Therefore, a stop and wait protocol is very inefficient over long or high bandwidth links.

Implementations

While stop and wait is time-inefficient, its requirement that the transmitter needs to buffer only one packet makes it very easy to implement. It is ideal for lightweight protocols such as Trivial FTP (TFTP), used to load kernals over a network by diskless workstations. TFTP must often be implemented in only a few tens of bytes of assembler, since it must be kept on a small ROM in the network card or BIOS of the diskless machine.

Additionally, since TFTP most commonly operates over ethernet, link latency is normally low enough that efficiency isn’t a problem. When link length becomes larger, more efficient protocols (such as go-back N or selective retransmission) are necessary for reasonable data transfer times.

group14_indigo:stop and wait protocol

Flow Control Techniques

Flow control is a technique for assuring that a transmitting entity does not overwhelm a receiving entity with data. A receiving entity typically allocates a data buffer of some maximum length for a transfer. When data is received, the receiver must do some amount of processing before passing the data to the higher level software. In the absense of flow control, the receiver’s buffer may fill up, and overflow while it is processing old data. Basically there are two types of flow control mechanisms.

Stop-and-Wait Flow Control

The simplest form of flow control is stop-and-wait and works as follows. A source entity transmits a frame. After reception, the destination entity indicates its willingness to accept another frame by sending back an acknowledgement to the frame just received. The source must wait until it receives the acknowledgement before sending the next frame. The destination can thus stop flow of data by just withholding the acknowledgement. This method fails if the message transmitted is very large.Care must be taken to split the large frames into smaller ones of size lesser than maximum buffer size. Smaller blocks also provide the following advantages -

LI> The longer the transmission, the more likely there will be an error, thus necessitating retransmission of the entire frame. With smaller frames, errors are detected sooner and a smaller amount of data needed to be retransmitted.
• On a shared medium that is usually desirable not to permit one station to occupy the medium for long and this causes delay at the other pending stations.

Sliding Window Flow Control

This flow control comes to the rescue where the buffer size is limited and pre-established. During a typical communication between a sender and a receiver the receiver allocates buffer space for n frames, where n is the buffer size in frames. Thus, the receiver can accept n frames and the sender can send n frames without waiting for an acknowledgment. To keep track of which frames have been acknowledged each is labelled with a sequence number. The receiver acknowledges a frame by sending an acknowledgement that includes the sequence number of the next frame expected. This acknowledgement also explicitly announces that the receiver is ready to receive n frames, begining with the number specified. Both the sender and receiver maintain what is called a window. The size of the window  is less than or equal to the buffer size.

As compared to stop-and-wait flow control the sliding window flow control has a far better  performance. This is because in a wireless environment data rates are very low and noise level is very high, so waiting for an acknowledge for every packet that is transfered does not seem feasible. Thus,Transferring data as a bulk ( Once the medium is allocated ) would yield a better performance in terms of higher throughput. So the choice is sliding window flow control.

Sliding window flow control is a point to point protocol assuming that no other entity tries to communicate until the current data transfer is complete.The window maintained by the sender indicates which frames he can send. The sender sends all the frames in the window and waits for an acknowledgement. The sender on receiving an acknowledgement indicating the next frame expected , shifts the window to the corresponding sequence number, thus indicating that frames within the window starting from the current sequence number can be sent.

Flow control also includes the control of data transfer between the PC and the Radio. While the PC is transferring data to the modem and if the modem detects a reception, the PC-Radio communication must be paused, giving higher priority to the incoming signal.

Group14_INDIGO:Problems faced

Some of the problems faced while preparing for our group A projects are:

1. We wanted show a demo on remote login using ssh but that did not work.

2. The demo on  remote login from a blackberry phone on to a remote system worked when there was a wifi connection , since ther is no wifi connection in college it created problems but thanks to ankan and harsh for helping us out.

group14_indigo:stop and wait protocol

SIMPLE FLOWCHART FOR STOP AND WAIT ARQ

DIAGRAM FOR STOP AND WAIT ARQ

PRACTICAL IMPLEMENTATION OF STOP AND WAIT ARQ

Group14_INDIGO:Mandatory blog

Team Name :Indigo

Team Members:Amulya Gururaj, Bhargavi C S, Meghana N, Tanushree A G

 Group A Project Chosen: Remote Login

 Group B Project Chosen:Stop and Wait ARQ

 Presentation Date of Group A Project:Completed on 23 september,2009

 Presentation Date of Group B Project: Not completed. Its on 25 november,2009 

Group A PPT Uploaded: Yes

Group B PPT Uploaded : No

 A Project Report Made: No

 B Project Report Made:No

Group A Project PROBLEMS FACED and SOLVED Blog Uploaded :Yes

Group B Project PROBLEMS FACED and SOLVED Blog Uploaded:No

group14_indigo:stop and wait protocol

the stop and wait protocol is a simple protocol.it is the simplest form of automatic repeat request method.automatic repeat request is an error control method for data transmission which uses acknowledgments and timeouts to achieve reliable data transmission over an unreliable service.

A stop-and-wait ARQ sender sends one frame at a time. After sending each frame, the sender doesn’t send any further frames until it receives an ACK (acknowledgement) signal. After receiving a good frame, the receiver sends an ACK. If the ACK does not reach the sender before a certain time, known as the timeout, the sender sends the same frame again.

The above behavior is the simplest Stop-and-Wait implementation. However, in a real life implementation there are problems to be addressed.

Typically the transmitter adds a redundancy check number to the end of each frame. The receiver uses the redundancy check number to check for possible damage. If the receiver sees that the frame is good, it sends an ACK. If the receiver sees that the frame is damaged, the receiver discards it and does not send an ACK — pretending that the frame was completely lost, not merely damaged.

One problem is where the ACK sent by the receiver is damaged or lost. In this case, the sender doesn’t receive the ACK, times out, and sends the frame again. Now the receiver has two copies of the same frame, and doesn’t know if the second one is a duplicate frame or the next frame of the sequence carrying identical data.

Another problem is when the transmission medium has such a long latency  that the sender’s timeout runs out before the frame reaches the receiver. In this case the sender resends the same packet. Eventually the receiver gets two copies of the same frame, and sends an ACK for each one. The sender, waiting for a single ACK, receives two ACKs, which may cause problems if it assumes that the second ACK is for the next frame in the sequence.

To avoid these problems, the most common solution is to define a 1 bit sequence number in the header of the frame. This sequence number alternates (from 0 to 1) in subsequent frames. When the receiver sends an ACK, it includes the sequence number of the next packet it expects. This way, the receiver can detect duplicated frames by checking if the frame sequence numbers alternate. If two subsequent frames have the same sequence number, they are duplicates, and the second frame is discarded. Similarly, if two subsequent ACKs reference the same sequence number, they are acknowledging the same frame.

Stop-and-wait ARQ is inefficient compared to other ARQs, because the time between packets, if the ACK and the data are received successfully, is twice the transit time (assuming the turnaround time can be zero). The throughput on the channel is a fraction of what it could be. To solve this problem, one can send more than one packet at a time with a larger sequence number and use one ACK for a set. This is what is done in go-back-N ARQ’S and the Selective-repeat ARQ’s.

where:

• t_I is the time needed to transfer bits of information only;
• t_O is the timeout;
• t_F is the time to transmit a packet (successfully or not)

the main advantage of the stop and wait ARQ’s is its simplicity.the main disadvantage is that it makes highly inefficient use of communication links.with the use of multiple frames for a single message,the stop and wait protocol does not perform well ,i.e. only one frame at a time can be in transit.this is a very brief introduction of stop and wait ARQ’s.

this video will help for better understanding of the stop and wait protocol: