Sliding Window Protocols? - Part 3

In the third part of this article we shall discuss about the types of sliding window protocols and how these protocols can be extended?

1. Stop and Wait: 

- This one is the simplest type among all the sliding window protocols. 

- Under this type, we have the stop–and–wait ARQ protocol as the simplest implementation.

- Both the transmit window and the receive window is 1 packet and the number of possible sequence numbers required is 2 i.e., 1+1 = 2. 

- The packets sent by the transmitter are marked alternatively as odd and even. 

- Therefore, the ACK packets are in the series of odd, even, odd, even and so on. 

- Now, suppose the transmitter sends an odd packet and immediately without waiting for an odd ACK sends the next even packet. 

- In such a case, it would receive an ACK saying that an odd packet is expected. 

- This leaves the transmitter in a state of ambiguity i.e., whether the receiver got both the packets or none of them.

2. Go-Back-N ARQ: 

- This sliding window protocol has a fixed w_r  (fixed at 1) and w_r  which is always greater than one. 

- Here, the receiver will not accept any packet other than the expected one from the sequence. 

- If the packet gets damaged or lost during the transmission, then the packets following the lost ne will not be accepted by the receiver until and unless it receives the lost one after re-transmission. 

- This ensures minimum loss of 1 RTT (round trip time). 

- This is why it results in inefficiency in using this protocol on the links where the packet loss is quite frequent. 

- Suppose a 3 bit sequence number is being used as in typical HDLC. 

- This means number of sequence numbers is 8 starting from 0 to 7. 

- This also means we have 8 possibilities. 

- Enough ACK information is required by the transmitter for distinguishing between those packets. 

- If 8 packets are sent back to back by the transmitter without stopping for ACK, then it will find itself in the same doubt as in the stop-and-wait case.

3. Selective repeat ARQ: 

- This one is the most general case of the sliding window protocols. 

- It works with a receiver that is more capable of accepting packets having the sequence numbers greater than what the current n_r is and storing them till the gap is filled. 

- The advantage is that discarding data before re-transmission is not necessary.

Ways to extend these protocols

1. The above types of the sliding window protocols don’t talk about reordering the packets after receiving them all. This will ensure that they don’t appear in wrong order. If the long distance can be bounded, the protocols can be extended to support this feature. The maximum mis- ordering distance can be used to expand the sequence number modulus N.
2. Not acknowledging every packet is also possible after the sending an ACK up on not receiving packets. For example, every 2^nd packet is acknowledged in TCP.
3. Informing the transmitter immediately about the presence of gap in the packet sequence is quite common and so HDLC uses a packet called REJ packet for this purpose.
4. During the communication, the window sizes may change if their sum remains in the limit defined by N. usually the transmit window size is reduced for slowing down the transmission in order to keep with the speed of the links and preventing congestion or saturation. 

Sliding Window Protocols? - Part 2

As discussed in part 1 of this article, the sliding window protocol is a type of the packet based data transmission protocol. The sliding window protocols are used in regulating the reliability factor of the data transmission. 

In this second part we discuss about the motivation behind this protocol and how it actually operates. 

- There are a number of communication protocols based up on the automatic repeat request for regulating the error control. 

- In such protocols, it becomes necessary for the receiver for acknowledging about the packets it received. 

- If the receiver does not send an ACK to the transmitter within a specified time period, then the transmitter assumes that the packet might have got lost, re-transmits it. 

- It is obvious that if a transmitter does not receives an ACK for the packet it had sent cannot actually know if the packet got delivered correctly. 

- If, suppose corruption is detected during error detection process on the receiver’s side; the receiver will simply ignore this packet and hence, will not send any ACK to the transmitter. 

- Now in the same way, the receiver also does not know whether the ACK it sent was received by the transmitter or it got lost or damaged during the transmission.

-  In such a case, the re-transmission must be acknowledged by the receiver in order to prevent the continuous re-sending of the data by the transmission. 

- In other cases it is simply ignored.

How the protocol operates?

- The current sequence numbers say n_t and n_r is assigned to transmitter and receiver respectively. 

- Both of them have their window sizes say w_t and w_r respectively.

- In simple implementations of the protocols these sizes are fixed however, they may vary when it comes to the larger and complex implementations. 

- For making any progress, it is necessary that the size of the window must be more than zero. 

- In a typical implementation, n_t denotes the packet to be transmitted. 

- Similarly n_r denotes the packet not received. 

- Both of these numbers increase with the time monotonically. 

- The receiver also has to keep an eye on the highest sequence number that has not been received yet. 

- We have another variable called n_s which is one number greater than the highest sequence number that has been received. 

- There are simple receivers which accept the packets only in the order of w_r = 1 which is nothing but same as the n_r. 

- But in some cases it can exceed 1. 

Now we can say that:

1.     Below n_r no packets have been received.

2.     Above n_s no packets have been received.

3.     It is only between n_r and n_s that some packets have been received.

- Whenever a packet is received, its variables are updated appropriately by the receiver and at the same time an ACK is transmitted with the updated value of n_r. 

- Similarly we have variable n_a used by the transmitter for tracking the highest ACK it has received. 

- Below n_a all the packets have been received but there is uncertainty about the packets between n_s and n_a i.e, the n_r. 

- There are certain rules that are always obeyed by the sequence numbers:

Ø  N_a ≤ n_r: The highest ACK the transmitter has received cannot exceed the highest n_r recorded by the receiver.

Ø  N_r ≤ n_s: The partially received packets’ end cannot be greater than the span of those fully received.

Ø  N_s ≤ n_t: The highest packet sent is always greater than the highest packet received.

Ø  N_t ≤ n_a + w_t: The highest ACK received and the window size set the limits for the highest packet sent.

Sliding Window Protocols? – Part 1

- There are many types of data transmission protocols of which one type is the packet based data transmission protocols. 

- These protocols have a feature called the sliding window protocol.

- The sliding window protocols are a great help wherever the in-order delivery of the data packets demand reliability. 

- For example, the Data link layer of the TCP (transmission control protocol) model and OSI model demand such reliability and thus use window sliding protocol. 

- According to the concept of the sliding window protocols, a consecutive number which is unique is assigned to each and every portion of the transmission i.e., the packets.

- These numbers are used by the receiver for placing the packets it will receive in their correct order. 

- Also, with the help of these numbers, the missing packets can be identified and the duplicate packets can be removed. 

- One problem regarding the sliding window protocols is that it has kept no limits for the size of these numbers that are required. 

- An unlimited number of data packets can be allowed to be communicated at any instant of time if limits are placed on the number of packets involved in transmission or reception. 

- By this, we mean using the sequence numbers of fixed size. 

- By term window we refer to the transmission side. 

- It actually represents the logical boundary or limit of the number of packets that the receiver has to acknowledge. 

- The transmitter has to be informed by the receiver for each ACK (acknowledgement) packet regarding the maximum size or the window boundary of the current receiver buffer. 

- For reporting the window size of the received buffer, a 16 bit field is used in the TCP header. 

- The maximum limit or boundary of the window that we can have is 2¹⁶ i.e., 64 KB. 

- When operating in the slow start mode, the counting of the transmitter begins with a low packet count.

- Gradually, the number of packets involved increases in every transmission after the ACK packet has been received. 

- Whenever it receives an ACK packet, the window slides logically by one packet for the transmission of a new packet. 

- On reaching the window threshold, one packet is sent by the transmitter for every one packet of ACK received. 

- Suppose the limit of the window is 10 packets and the transmitter is in slow start mode. 

- Then, first one packet will be transmitted followed by another two. 

- Between these two transmissions, it will send an ACK packet also. 

- This process will continue until the limit of 10 has reached. 

- After crossing the limit, the transmission is restricted to one i.e., for every ACK packet received only one data packet is transmitted. 

- When viewed during simulation, it seems as if the window is shifting by distance of one packet whenever an ACK packet is received. 

- For avoiding the traffic congestion, the sliding window protocol works up a great deal.

- In this way the application layer would not have to worry about transmission the next set of data packets. 

- It can continue to do so since the sliding windows of the packet buffer will be implemented on both the sides i.e., the receiver’s and the sender’s side by the TCP. 

-However, the network traffic influences the window size dynamically to a great extent. 

- In order to achieve the highest possible throughput, care should be taken for not forcing the transmitter to stop the transmission before one RTT or round trip delay time by the sliding window protocol. 

- The bandwidth delay product of the links in the communication should be less than the limit of the data amount that can be sent before sending ACK packet. - If this condition is not met, the links’ effective bandwidth will be limited by the protocol. 

Explain EiffelStudio? What technology is used by EiffelStudio?

For Eiffel programming language, the development environment is provided by the Eiffelstudio. Both of these – the Eiffelstudio and Eiffel programming language have been developed by Eiffel software. Presently the version 7.1 has been released.

- Eiffelstudio consists a number of development tools namely:

1. Compiler
2. Interpreter
3. Debugger
4. Browser
5. Metrics tool
6. Profiler
7. Diagram tool

- All these tools have been integrated and put under the single user interface of the Eiffelstudio. 

- This user interface in turn is based on several UI paradigms that are quite specific to one another. 

- There has been done effective browsing through ‘pick and drop’ thing. 

- Eiffelstudio supports a number of platforms including the following:

1. Windows
2. Linux
3. Mac OS
4. VMS and
5. Solaris

- This Eiffel software product comes with a GPL license. 

- However, a number of other licenses are also available. 

- Eiffelstudio falls under the category of open source development. 

- The beta versions of the product of the following release are made available to the public at regular intervals. 

- The participation of the Eiffel community in the development of the product has been quite active. 

- A list of the open projects has even made available on the origo web site. 

- The host of this site is at ETH Zurich. 

- Along with the list, information regarding the discussion forums, basic source code for check out etc. also has been put up. 

- In the month of June 2012, the last version 7.1 was released and the successive beta releases were made available very soon after that.

Technology behind EiffelStudio

- The compilation technology used by the Eiffelstudio called Melting Ice is unique to the Eiffel software and is their trademark.

- This technology integrates the interpretation process of the elements with the proper compilation process. 

- This technology offers a very fast turnaround time. 

- This also means that the time taken for recompilation depends up on the size of the change to be made and not on the overall size of the program. 

- Such melted programs even though can be delivered readily but still a finalization step is considered important to be performed before the product is released.

- Finalization step involves a very highly optimized compilation process which takes a long time but the executable generated is optimized.

- The interpretation in eiffelstudio is carried out through what is called the byte code-oriented virtual machine. 

- Either .NET CIL or C is generated by the compiler. 

History of Eiffelstudio

- The roots of the Eiffelstudio date back to when the Eiffel was first implemented by interactive software engineering Inc. 

- The Eiffel software was preceded by the interactive software engineering Inc. -The first implementation took place in the year of 1986. 

-The current technology used in Eiffelstudio evolved from the earlier technology called the ‘Eiffel bench’ that saw its first use in the year of 1990. 

- It was used along with the version 3 of the Eiffel programming language. 

- In the year 2001, the name Eiffel bench was changed to what we know now, the ‘Eiffelstudio’. 

- This was also the year when the environment was developed to obtain compatibility with the windows and a number of other platforms. 

- Originally, it was only available for Unix platform.

- Since 2001, Eiffelstudio saw some major releases with some new features:

1. Version 5.0 (july 2001): The first proper version. Saw integration of the eiffelcase tool with the eiffelbench as its diagram tool.
2. Version 5.1 (December 2001): Support for .NET applications. Also called the eiffel#.
3. Version 5.2 (November 2002): The debugging capabilities were extended, an improved mechanism for C++ and C was introduced, eiffelbuild, roundtripping abilities etc. were added.

Give an overview of The diagram Tool of EiffelStudio?

Eiffelstudio is a rich combination of a number of development environment tools such as:

1. Compiler
2. Interpreter
3. Debugger
4. Browser
5. Metrics tool
6. Profiler
7. Diagram tool

In this article we shall discuss about the last tool of Eiffelstudio i.e., the diagram tool. 

A graphical view of the software structures is provided by the Eiffelstudio’s diagram tool. This tool can be used effectively in both:

1. Forward engineering process: In this process it can be used as design tool that uses the graphical descriptions for producing the software.
2. Reverse engineering process: In this process it produces the graphical representations of the program texts that already exist automatically.

The changes that are made in any of the above mentioned two processes are given guaranteed integration by the diagram tool and this is called round trip engineering. 

It uses any of the following two graphical notations:

1. BON (business object notation) and
2. UML (unified modeling language)

By default the notation used is BON. The Eiffelstudio has the capability of displaying several views of the classes and their features. 

It provides various types of views such as:

1. Text view: It displays the full text of the program.

2. Contract view: It displays only the interface but with the contracts.

3. Flat view: It displays the inherited features as well.

4. Clients: It displays all the classes with their features that depend up on other class or feature.

5. Inheritance history:  It shows how a feature is affected when it goes up or down the inheritance structure.

There are a number of other views also available. There is an user interface paradigm that is based on holes, pebbles and other development objects and the Eiffelstudio relies heavily on this. 

Software developers using Eiffelstudio have to deal with abstractions that represent the following:

Ø  Classes

Ø  Features

Ø  Breakpoints

Ø  Clusters

Ø  Other development objects

- The way they deal with these things are same as that of the way in which the objects during run time are dealt by the object – oriented in Eiffelstudio.

- In Eiffelstudio, wherever a development object appears at the interface, it can be picked or selected irrespective of how it is visually represented i.e., what name is given to it and what symbol and so on. 

- To pick a development object you just have to right click on it. 

- The moment you click on it the cursor changes to pebble (a special symbol) that corresponds to different types of the object such as:

1. Bubble or ellipse for class
2. Dot for breakpoint
3. Cross for feature and so on.

- As the position of the cursor changes, a line appears displaying the original position and current position of the object. 

- The object can be dropped at any place where the pebble symbol matches the cursor.

- An object can also be dropped in a window that is compatible with it. 

- Multiple views can be combined together to make it easy browsing through the complex structure of the system. 

- This also makes it possible to follow the transformations such as re-naming, un-definition and re-definition that are applied to the features while inheriting.

- The diagram tool of the Eiffelstudio is the major helping hand in the creation of the applications that are robust, scalable and fast. 

- It helps you to model your application just the way you want. 

- It helps in capturing your requirements as well as thought processes. 

- The tools of the Eiffel studio make it sure that you don’t have to use separate tools to make changes in the architecture of the system while designing.

How to fix the bitmap that failed to stabilize error?

It may happen that the bitmap might fail to stabilize the error in silk test. It is quite a frequently occurring problem but needs to be addressed seriously. 

Most of the times you might have been asked for or required creating a test case that can be straight-forward put to use in carrying out the bitmap verification. 

You set down to create such a test case and go for the verification of the full window while the recording is in progress. 

During the execution of the test case all of a sudden you get an error as stated below:

“Error: bitmap failed to stabilize”

Finding such an error can even be a nightmare for you and sometimes the whole quality assurance team may fail to think of a solution for this. You won’t even find solution for this in the silk test documentation. 

- There are situations that the bitmap issue might be stated in a described state.

- It is only when there is some instability in the verified windows that is to say that some element of the screen is experiencing frequent changes. 

- In such a situation, the stable copy of the bitmap is captured by the silk test automation tool. 

- If in case it could not get the window tested within a specific time interval, then it generates an exception saying “E _ BITMAP _ NOT _ STABLE”.

- Different approaches to such a situation might be used by the different quality assurance engineers. 

- You need to set the below mentioned options to 0 in the 4test code:

Agent. Set option ( OPT _ BITMAP _ MATCH _ COUNT, 0 )

Agent. Set option ( OPT _ BITMAP _ MATCH _ TIME OUT, 0 )

Agent. Set option ( OPT _ BITMAP _ MATCH _ INTERVAL, 0 )

- Another way of doing this is going to the options menu, then agent, then bitmap and change the required values. 

- Another error occurs while capturing image via the capture bitmap method. 

- In some cases when this method was executed the silk test was observed giving the following error:

“bitmap region size (some coordinate) is not valid”

- In such a case the getrect method can be used for obtaining the coordinates of the bitmap. 

- The getrect method returns the following:

1. X coordinate of the active bitmap
2. Y coordinate of the active bit map
3. Width of the active image
4. Height of the active image

- For capturing an image, one requires two coordinates of the image i.e., (x1, y1) and (x2, y2).

- Here the coordinates correspond as follow:
1. First co-ordinate is for the top left corner of the image whereas

2. The second coordinate points to the right bottom corner of the image. 

- You can even take help of the identify object feature of the silk test workbench for discovering these coordinates. 

- To avoid these errors it is necessary that you fix the screen resolution in the first go itself i.e., using the first script itself using the following function:

Maximize()

- Once this function has been implemented, and then you should go for capturing the screen shot. 

- If this is not done then there are chances that the screen size may keep on changing i.e., it may expand or shrink according to the settings that you made for the previous scripts. 

- This may also cause the coordinates to shift on the screen which may cause the script to capture something else than what was expected. 

- However, the getrect method can return both absolute as well as the relative methods. 

What is VO (Virtual Object) browser extension in Silk Test?

The silk test automation tool comes with several extensions such as the DOM extension, VO browser extension and so on. 

VO here stands for the ‘virtual object’. 

About Virtual Object 'VO' Browser Extension

- This browser extension is an add–on component for the silk test and is employed during the testing of the web sites and web applications. 

- This virtual object browser extension makes use of a special technique known as the sophisticated pattern recognition technique in order to facilitate the identification of the objects rendered by the objects. 

- The web pages are viewed by the virtual object browser extension as they are in actual. 

- The virtual object browser extension does not opt for the recognition of the HTML tags present in the code of the web application.

- The objects present in that web page or web application are viewed by the virtual object browser extension. 

- These objects may include tables, links, images, compound controls and so on. 

- The technology behind these objects is well ignored by the virtual object browser extension just as we the users do.

- Objects are recognized by the silk test based up on the following aspects of an object:

1. Control type
2. Caption
3. Associated text
4. Control index
5. Location and
6. Window ID

Actually silk test has got two methods for the recognition of any object present in the application under test or AUT and they have been stated below:

1. Virtual object recognition
2. Document object model

Both of these methods produce the same result however they cannot be totally inter changed within a test script. 

The objects that are a part of the web applications which run in a browser such as the following need to be dealt with in a special way:

1. Java applications
2. Visual basic applications and
3. Power builder applications

- Technologies behind such applications are not directly supported by the silk test rather these technologies are provided support by the means of some optional extensions.

- These extensions have to be installed separately. 

- The extensions that have been installed are displayed in the option set of the silk test. 

- All you need to do is check the extension that you need to use and un-check the others. 

- There are certain default settings that can be configured manually by the user. 

- In some cases, a combination of the add ins and extensions might be treated mutually exclusive. 

- Another possibility is that some of the add-ins or the extensions might be supported in the new versions of the silk test. 

- A third possibility is that some of those add ins and extensions might be supported by the earlier versions of the silk test. 

- A table mechanism is used by the silk test for the recognition of the objects and as a means to isolate the variable name from the description of the object that is used by the operating system for accessing the objects during the run time. 

- The GUI declarations of an application are placed in a test frame file usually by the silk test. 

- For each and every object in a window there is available, a GUI declaration which  consists of the class of the object as well as its identifier which is nothing but the variable that was used in the test script. 

- It may also consist of an object tag definition. 

- The following are the capabilities that are provided by the silk test for defining an object tag:

1. String
2. Array reference
3. Function
4. Class and index number
5. Multiple tags
6. Browser specifier

What are file types used in Silk Test?

Silk test consists of many file types which have been discussed in this article. There are various types of files that are used by the silk test in the process of automation testing. 

Each of the files is used for a specific purpose or we can say function such as certain files are required by the silk test for the creation and execution of the tests. 

Now we shall discuss the different file types available one by one:

1. Test plan (.pln): This file type in silk test facilitates the creation of the test suites. But the test suites can be created lonely if this file type is combined with the test scripts.

Testone

          Script: test.t

          Test case: one

Testtwo

          Script: test.t

          Test case: second

Here in the above example the main test script file is test. t. on the other hand the ‘one’ and the ‘second’ are the names of the test cases in the main script file test.t. Whenever this file type is run the test cases one and second are automatically picked up by the main script file and executed.

2. Test script (.t): This file type in the silk test is used while writing the actual test scripts. Whenever such a file is in run session the test one and test two test cases are executed by it in a predefined order and at the end the note pad application is closed.
3. Frame file (.inc): The windows and the controls present in the AUT or application under test are defined by an abstraction layer. These windows as well as the controls are referenced later in .t files.
4. Result file (.res): This file type consists of all the test run results which have the names of all the passed as well as failed tests along with their suitable descriptions. These file types may or may not contain log messages.

Leaving out the result file (.res) type, almost all the other file types are based up on text. Therefore, the editing of all those files can be edited either using the silk test IDE or by using a text editor.

In the silk test version that was released in the year of 2006, the files can be saved in either of the two formats namely:

1. ANSI format or
2. The UTF – 8 format

5. Project (.vtp): This file type is saved with an extension of 'verify test project' and is used as storage for the locations as well as the names of the files that are currently in use by some project. With this file type there is another associated file type .ini extension since it is an initialization file.
6. Data driven script (.g.t): This file type stores the data driven test cases which are use to pull out data from the data bases.
7. Suite (.s): With the help of this file type the sequential execution of several test scripts is possible.  
8. Text file (.txt): This is an ascii file type and can be used for the following purposes:

a)   For storing a data that can be used for driving a test.

b)   For printing a file in some another document.

c)   The test automation file is accompanied by this file type as a read me file.

d)   For transformation of a tab delimited plan in to a silk test plan.

Entire above discussed source files are compiled and stored as the ‘pseudo code object files’ at either of the times:

1. When the files are loaded or
2. When any change has occurred in the file types. 

What is a Run-Time Data Table? Where can I find and view this table?

The quick test professional always makes it a point to produce a run time data table at the end of every run session so that the user can have a live view of the data table that is currently associated with the test being carried out at that time. 

What is a Run-Time Data Table?

- While the run session is still in progress, the run time data table is displayed in the data table pane of the quick test professional window. 

- This is to make it easy for the user to view any changes that are constantly made to data during the run session.

- At the end of the run session, this run time data table is closed and in the data table pane the stored design time data table is displayed again in the place of the run time data table. 

- In some of the cases the data which entered in to the run time data table during the run session is not saved along with the test.

- At the end of the run session the data in the table is finalized and is displayed is run time data table column of the results window of the test. 

- The name of the run time data table was derived from the fact that it is generated during the run time. 

- With every script or component there is an associated run time data table which serves the purpose of displaying the data.  

- One run time data table has the property to access the data from some other data table during the run time. 

After a particular test has been executed with either of the following:

1. Data table parameters and
2. Data table output value steps

The following are displayed by the run time data table:

1. Parameterized values that were used during the testing and automation and
2. Output values that were saved in the data table during the run session.

Certain data table methods are provided by the quick test professional with the help of which the user can alter the data table as required and these are:

1. Add sheet: This data table method can be used to add sheets in to the pre existing run time data table. Syntax used is:

Datatable.addsheet (name of the sheet)

2. Delete sheet: This data table method as obvious from its name is used for deletion of the already added sheets in a run time data table. However at one time only one sheet can be deleted. Syntax used is:

Datatable. Deletesheet (“ID of the sheet”)

3. Get sheet count: This data table method gives you the number of sheets that you have in your run time data table. Syntax used is:

Datatable. Getsheet count

4. Get sheet: This methods returns the sheet specified from the run time data table by the user. Syntax used is:

Datatable. Getsheet( ID of the sheet)

5. Get row count: Returns the number of rows present in a particular sheet of the run time data table. Syntax used is:  datatable. Getrowcount
6. Value: This data table method serves two purposes i.e., using it you can either obtain value of a specified cell or you can modify the value of the cell. Syntax for both the cases is:

Variable = datatable. Value( name of the parameter, name of the sheet)

Variable = datatable. Value( name of the parameter, name of the sheet) = value

  There are some other data table methods also like:

1. Set current row
2. Set next row
3. Set previous row
4. Import
5. Export and so on.