Difference between TCP and UDP

There are two types of internet protocol (IP) traffic, and both have very different uses. TCP(Transmission Control Protocol). TCP is a connection-oriented protocol, a connection can be made from client to server, and from then on any data can be sent along that connection.  Reliable - when you send a message along a TCP socket, you know it will get there unless the connection fails completely. If it gets lost along the way, the server will re-request the lost part. This means complete integrity, things don't get corrupted. Ordered - if you send two messages along a connection, one after the other, you know the first message will get there first. You don't have to worry about data arriving in the wrong order. Heavyweight - when the low level parts of the TCP "stream" arrive in the wrong order, resend requests have to be sent, and all the out of sequence parts have to be put back together, so requires a bit of work to piece together. Streaming: Data is read as a "stream," with nothing distinguishing where one packet ends and another begins. There may be multiple packets per read call. Examples: World Wide Web (Apache TCP port 80), e-mail (SMTP TCP port 25 Postfix MTA), File Transfer Protocol (FTP port 21) and Secure Shell (OpenSSH port 22) etc. 2.  UDP(User Datagram Protocol). A simpler message-based connectionless protocol. With UDP you send messages (packets) across the network in chunks. Unreliable - When you send a message, you don't know if it'll get there, it could get lost on the way. Not ordered - If you send two messages out, you don't know what order they'll arrive in. Lightweight - No ordering of messages, no tracking connections, etc. It's just fire and forget! This means it's a lot quicker, and the network card / OS have to do very little work to translate the data back from the packets. Datagrams: Packets are sent individually and are guaranteed to be whole if they arrive. One packet per one read call. Examples: Domain Name System (DNS UDP port 53), streaming media applications such as IPTV or movies, Voice over IP (VoIP), Trivial File Transfer Protocol (TFTP) and online multiplayer games etc.

Cookies and its types? Where are cookies used?

A cookie or an HTTP cookie can be defined as a message used by an origin website to send the information about the state to the browser of the user and by the browser to send the information about its state to the origin site.

An HTTP cookie is known by many names such as web cookie, browser cookie etc.

The information of the state that is sent across the origin site and the user’s browser is used for the purpose of:

- Authentication
- Identification of the session of an user
- Preferences of the user and
- Contents of the shopping cart

In other word HTTP cookies are used for any purpose that can be accomplished using the process storing text data on the computer of the user.

Characteristics and Uses of Cookie
- The main characteristic of Cookies is that they cannot be programmed and thus, cannot carry any kind of viruses or worms.

- Any malware cannot be installed on the host system with the use of a cookie. So they are safe to this extent.

- However, cookies can be effectively used by a spyware to track the browsing activities of the users.

- This is a major privacy concern and has prompted European and US law makers to take action in the past few years.

- Cookies are very easy to steal and are thus often misused by the hackers.

- Hackers steal the cookies and use them to gain access to the web account of the victim.

- Cookies were first used to solve the problem of implementation of the shopping cart.

- Initially the cookies were developed for the Netscape browser.

- They were used to check if the earlier visitors visited the site again.

- Later cookies were developed for internet explorer and other browsers.

- The concept of the cookies was not widely known to the public at that time.

The term “HTTP cookie” came into existence in the year of 1994. It has been derived from “magic cookie”.

What are Magic Cookies?
- Magic cookie was actually a data packet that a program receives and sends again to the program on the other side without altering the contents of the packet.

- Magic cookies were used in computing systems long back and were introduced in web communications by Lou Montulli in June 1994.


The development of a cookie for formal specifications is always in progress. Till date many types of cookies have developed. They have been discussed below:

Session cookie:
- This cookie has a lifetime equal to the time period of the user using the website.
- These cookies are automatically deleted after the end of a session.

Persistent cookie:
- These cookies last even after the session has expired.
- If a persistent cookie has its maximum age set to one year, then till the one year is over, the cookie will be sending information to the server every time the website is visited.
- These are also called tracking cookies.

Secure cookie:
- These cookies are used by the browser if it accessing server through an HTTPS connection.
- This ensures that the cookie is always encrypted during the transmission of the information.
- This prevents cookie theft.

HTTP only cookie:
- This type of cookie is mostly supported by all the modern browsers.
- On a browser which supports HTTP, an HTTP only cookie is used during transmission of HTTP requests.
- It restricts the access from other non HTTP scripts.

Third party cookie:
- The first party cookies are set with the same domain or sub domain in the address bar of the browser.
- But, third party cookies are set with various domains other than the one mentioned in the address bar.

Super cookie:
- A cookie with a public suffix domain like .co.uk, .com etc.

Zombie cookie:
- This cookie is automatically recreated after its deletion.

What is meant by concurrency testing?

INTRODUCTION TO CONCURRENT TESTING

1. Concurrency testing employs many users at a time and therefore it is considered to be a type of multi- user testing.

2. Concurrency testing was invented in order to determine what happens if many users are accessing the same data base records, modules or application code.

3. Other than this, concurrency testing also identifies the use of single threaded code, dead locking, locking semaphores and locking and it is also effective in measuring the level of these aspects.

4. While carrying out the concurrency testing several users perform same kind of task on the same application and that too at the same time.

5. The application serves too many users at a time.

TOOLS FOR PERFORMING CONCURRENT TESTING
Several tools are available for performing concurrency testing but we would recommend you load Runner since it helps you create concurrency at a point you wish.

- All you need to do is create a test scenario after you have recorded and improved your scripts using the virtual user generator.

- You can decide and add how many users you want your scripts to support.

- You should input the number of users in the controller component of this testing tool.

- There are several ways to add user like gradual ramp- up or spike, stepped etc.

- You can choose for yourself which way you want the users to be added.

- This is the most effective way to create concurrency.

- Apart from the multi user testing, the concurrency testing tests one application over the other one.

LEVELS OF CONCURRENCY TESTING
Two levels of concurrency testing have been developed so far and they have been discussed below:

# 1st Level:
- This involves concurrency testing of one application being executed on the top of another application.

- We can illustrate this by a simple example; you receive an incoming call while playing some game on your cell phone. The game will go to paused state. This is the simplest example we can give.

# 2nd Level:
- This involves concurrency testing of one application being executed on the top of other two applications.

- This can also be illustrated with a similar example, you receive an incoming call while playing games and while you are on the call you receive an SMS. The game is paused.

- Apart from just testing the multi user capacity of the software, concurrency is also responsible for finding out the bugs like dead lock, live lock, data race and data corruption.

- These bugs usually occur when the parallel processing is implemented in the application.

- If you are also using the user scenario apart from the test scenario your concurrency testing will yield much better results.

- Some applications make use of more than one module where some accept parallel processing and other are sequential.

- Identifying the type of modules can help you in writing effective test cases against them which in turn will reflect in your testing.

This is the internet era. Almost everyone is using web and web applications all over the world. Such a huge number of users require great stress handling capacity for the servers. If the servers are not able to take the load they often slip in to the position of the dead lock.

Concurrency testing is a way to ensure that such kinds of situations do not occur. Therefore concurrency testing is important. Performance is the basic aspect that is tested most in the concurrency testing.

Number of users using the application at a time equals to the number of hits per second. With the growing number of internet users world wide more and more security is needed over the web. Concurrency testing is one such measure which has helped to a great extent for improving the cyber standards.

LoadRunner Analysis: Hints ‘n’ Tips.

The LoadRunner Analysis tool can either be a godsend or the devil’s daughter. I think most Performance Analysts have a love-hate relationship with the Analysis tool…and refer to it as some sort of necessary evil.

With a little bit of patience, the Analysis tool is actually quite powerful and can be used to produce some fantastic graphs and information for your reports.

Everyone seems to learn their own tricks, if you have any more of your own, please submit these as comments.

In no particular order:-

• Setting the Granularity.
  The granularity affects the graph smoothing, or number of data points. A high granularity value will reduce clutter and improve readability, but it may hide events such as spikes. The trick is to adjust the granularity to maximize readability but accurately represent any important events. Caution, however for larger performance tests setting the granularity too low may cause the Analysis tool to hang for a few minutes.
• Annotations – Comments and Arrows.
  Make use of comments and arrows to annotate important events on the graph. In addition, these are useful for labeling data lines…particularly when there are lots of lines and you want to highlight just one of two of them.
• Focus on just a few transactions.
  Performance tests can have sometimes hundreds of transactions and this can generate some very busy graphs. Decide on 3-5 transactions that have the highest business value or are of particular interest…focusing your analysis on just a few transactions is more valuable to the readers of your report.
• Set your Y-Axis to be the same for all graphs.
  Graphs should be easily comparable and “tell the same story”. By default the Y-Axis is set to Automatic, which sets the minimum and maximum scale to match your data. Go to Display Options > Advanced > Axis tab, and change Minimum and Maximum values from “Auto” to something sensible. Percentage graphs should always be ranges from 0% to 100%.
  As a general rule, your Y-Axis scale should always start at zero and your ideal or SLA level should be approximately one-third up the scale. People we automatically assume response times in the lower third of your graph are “good” and the upper two-thirds are “poor”.
• Tell a Story
  All graphs you present via the Analysis tool should tell a story. Performance Testing is there to answer the question of whether the application will scale to the load level required in production…and as a performance analysis you should produce graphs to provide evidence of either the success or failure of this performance testing.
• Don’t Take Screenshots with the Print Screen button
  Screenshots look bad, instead use Edit > Copy To Clipboard > Graph. Alternatively, you can export graphs as image files. Go to Display Options > Advanced > Export tab. By exporting in Metafile format you will avoid any blocky pixelation which looks great for presentations or printed reports. I also recommend setting the border background colour to White for a nicer look (Display Options > Advanced > Chart > Panel > Background > Color).
• Filter on Peak Load
  When analysing a peak load test, make use of a global filter to limit your analysis to the time that was spent AT PEAK LOAD, so that your response times do not include values measured during ramp up.
• Percentile Graph Analysis
  Look at each response time in the percentile graph to see if there are any weird “step” patterns. The lines in the percentile graph should always be smooth, if there is a weird “step” pattern that could indicate abnormal behaviour.
• Import External Data
  Remember that you can import data from external monitors/text files (Tools > External Monitors > Import Data).
• Merging graphs
  This is useful but don’t put too many values on the graph, or it will be hard to interpret. Combine multiple data types can be confusing. Use Annotations.
• Edit the Transaction Summary in Excel or Word.
  The Transaction Summary can be easily copied and pasted into either Word or Excel, this allows it to be easily edited. For example, removing columns and reduced the decimal points displayed.
• Only use Complete Data
  After initially opening a LoadRunner result, only summary data is available. In the lower-left corner, you will notice the generation of Complete Data. You should always wait until this background process completes before editing graphs.
• Remove the data point markers
  Use Display Options > Graph Type to quickly remove all the data point marks for your line graph. This makes it look a lot less cluttered.
• Make use of Templates
  This feature (Tools > Templates) allows you to quickly apply the same graphs and formatting from one Analysis scenario to another. This is great for comparing results; however always double-check filters to after applying a template to ensure you are not filtering out any important data.

I hope you all find this bag of tricks useful. I know I’ve learnt a thing or two by putting it together. ;-)

Scripting RMI with Loadrunner VuGen 9.5x and 11

The Java Remote Method Invocation (RMI) is a Java application programming interface that supports an object-oriented way of  remote procedure calls (RPC). In this article I show you two ways to create performance tests scripts with Loadrunner for RMI-driven applications.

As RMI is a Java-specific protocol, the Java vuser or the Java Record replay protocols mush be used in the Virtual User Generator.

I demonstrate two approaches:

1. Code RMI calls manually – using Java VUser script type
2. Record the network traffic of the RMI application’s client and then play it back – using Java Record replay script type

Note: The respective Loadrunner licenses are necessary to run the created tests in the Controller.

The test application

I created a small RMI client-server test application using the Java Spring Framework. For simplicity the RMI server application is packaged as a WAR and can be run in a java web container (e.g. Tomcat). The client has been packaged into a single JAR file for easy execution. This JAR file will be reused in VUgen.  It contains the RMI interface of the application under test and the necessary Spring Framework APIs for easy RMI access.

If you would like to try the test application, here are the necessary tools:

• Java Development kit (e.g. 1.6)
• Apache Maven for build and dependency management
• Apache Tomcat to execute the RMI test server application

The test application can be downloaded here: spring-rmi-poc-test-app.zip

Using Java VUser script type (using Loadrunner Virtual User Generator 9.5x)

1. Create a new Java VUser script
2. Use File/Add files to script… menu to add the test client jar to the script. Adding JAR files this way ensures that the contained classes will be placed to the Classpath, therefore will be available in script.
3. Code the RMI call manually, as it would be done in any other Java program. In our example we used Spring Framework to facilitate that.

JAR file added to Java virtual user script

/* * LoadRunner Java script. (Build: 3020) * * Script Description: * */ import lrapi.lr; import org.springframework.remoting.rmi.RmiProxyFactoryBean; import rmitest.intf.AccountService;   public class Actions {     RmiProxyFactoryBean proxy = new RmiProxyFactoryBean();     public int init() throws Throwable {     // TODO update here the name of the server and the port:     proxy.setServiceUrl("rmi://localhost:1199/AccountService");     proxy.setServiceInterface(AccountService.class);     proxy.afterPropertiesSet();       return 0;   }//end of init     public int action() throws Throwable {     try {       lr.start_transaction("getAccounts");         Object obj = proxy.getObject();       AccountService service = (AccountService) obj;       service.getAccounts("akarmi");         lr.end_transaction("getAccounts", lr.AUTO);     } catch (Exception e) {       lr.end_transaction("getAccounts", lr.FAIL);     }     return 0;   }//end of action     public int end() throws Throwable {     return 0;   }//end of end   }

Using Java Record replay script type

(This script type available in VuGen 9.5, however it functioned for me only in Loadrunner 11 well.)

This approach is useful, if it is possible to run the RMI client application together with Loadrunner capturing. For complex or platform- or environment-dependent application it is usually not the case however.

To start the example RMI client the following batch file has been created. It is to be specified in the Start Recording dialog, via seting Application type to „Executable\Batch”. I set the working directory to point the directory of the jar file.

1	%JAVA_HOME%\bin\java -jar spring-rmi-jar-with-dependencies.jar

Ensure, that in the Recording Options the RMI protocol is selected.

RMI is selected as a recorded protocol

The client application should now start and the RMI traffic will be recorded and transformed into java code.

Start recording dialog to capture RMI client application’s traffic

Here is a sample generated raw code:

/* * Code generated by RMI support (Build: _build_number_) - Vugen [JAPATA] for LoadRunner Version 11.0.0 * Session was recorded on: Thu Dec 10 14:34:35 2011 * * Using VM version : Executable * Script Author    : Sudhakar * Script Description: * */   import lrapi.lr; import java.util.Properties;   public class Actions {   // Public function : init   public int init() throws Throwable {     // Set system properties...     _properties1 = System.getProperties();     _properties1.put("sun.desktop", "windows");     _properties1.put("sun.jnu.encoding", "Cp1251");     _properties1.put("sun.management.compiler", "HotSpot Client Compiler");     _properties1.put("sun.java.launcher", "SUN_STANDARD");     System.setProperties(_properties1);       // Installing RMISecurityManager     if (System.getSecurityManager() == null)     System.setSecurityManager(new java.rmi.RMISecurityManager());     return 0;   }//end of init     // Public function : action   public int action() throws Throwable {     // Lookup a remote object...     _rmiinvocationhandler1 = (org.springframework.remoting.rmi.RmiInvocationHandler)java.rmi.Naming.lookup("rmi://localhost:1199/AccountService");     _string1 = "org.springframework.remoting.support.RemoteInvocation __CURRENT_OBJECT = {" +     "java.lang.Object arguments[] = {" +     "java.lang.Object arguments[0] = #akarmi#" +     "}" +     "java.util.Map attributes = _NULL_" +     "java.lang.String methodName = #getAccounts#" +     "java.lang.Class parameterTypes[] = {" +     "java.lang.Class parameterTypes[0] = {}" +     "}" +     "}";       _remoteinvocation1 = (org.springframework.remoting.support.RemoteInvocation)lr.deserialize(_string1,0);  // RMIComponent     _object1 = _rmiinvocationhandler1.invoke((org.springframework.remoting.support.RemoteInvocation)_remoteinvocation1);     return 0;   }//end of action     // Public function : end     public int end() throws Throwable {     return 0;   }//end of end     // Variable section   java.lang.Object[] _object_array1;   java.util.Properties _properties1;   org.springframework.remoting.rmi.RmiInvocationHandler _rmiinvocationhandler1;   org.springframework.remoting.support.RemoteInvocation _remoteinvocation1;   java.lang.String _string1;   java.lang.Object[] _object_array2;   java.lang.Object _object1; }