Saturday, August 17, 2013

TCP- Close wait simulation - Part 3

Lets try to do some dirty way of coding to produce close_wait!

Check out my server code! I am opening up new socket and waiting for request from client!
Once request is received, writing out a message to client and closing the connection then and there!
Server Code

In Client code I am creating new connection with Server and puting the clinet into sleep mode with out closing the connection.
Client Code

This will results as bellow!

Tuesday, August 13, 2013

TCP- Close wait simulation - Part 2

In my last blog , I gave a brief idea about TCP and TCP states, Lets check how its work in real network by simulating the TCP connection using NS2 simulator.

So what is NS2?

NS2 is a discrete event network simulator. It is aimed at network research, and supports simulation of various facets of networking, including TCP, multicast, and routing protocols.

You can easly install NS2 in Ubunutu using "Ubunutu Software Center", as usual make use of your terminal and install. sudo apt-get install ns2 nam xgraph.

Below NS2 Script contain TCP - TCP compare.

Below NS2 Script contain TCP-UDP compare

you can run these codes using ns .tcl

Above NS2 scripts help you to simulate how TCP's functionality in the real network.
Lets see what has happened!

As shown in Figure 1, the network model was configured with two TCP (TransmissionControl Protocol) flows for two milliseconds and recorded observation in trace files.

Figure 1
Trace files were plotted using “xgraph” utility and it has been shown in figure 2
Figure 2
According to the results given by the experiment, TCP flows fairly shared the network bandwidth.

As shown in Figure 3, additional another experiment was conducted in respect to model the TCP flow and UDP (User Datagram Protocol) flow in shared network environment, which experiment was inspected for two milliseconds. Furthermore, observations were recorded in the trace file as previous experiment.
Figure 3 
Second experiment’s trace files were plotted using “xgraph” utility and it has been shown in Figure 4.

In accordance with the second experimental result given in the Figure 4, UPD flow was taken over the shared network resource from TCP flow and it did not moderately shared the band with it .

Figure 4

According to Figure 5, in first experiment; first TCP flow was shared the bandwidth with second TCP flow. In second experiment; TCP flow was trampled by UDP flow.Hence, as a conclusion of those two experiments, TCP Shares the network resource fairly.Nevertheless, UPD does not share the network resource.

Even though this is irrelevant to this topic, this help us to understand the behavior of the TCP connections.

Sunday, August 11, 2013

TCP - Close wait simulation - Part 1

In this blog series i will try to explain how to simulate CLOSE_WAIT state of TCP in java . In order to do that as a prerequisite you have to understand the TCP. Therefore i refer to refer to "Computer Network" by Anrew Tanenbaum [1] in this first part of this series. In my next blog post i will simulated the behavior of the TCP using NS2 network simulation tool.Thereafter, I will be show simple code snippet  to demonstrate the CLOSE_WAIT.

So lets start with TCP.......


Transmission Control Protocol (TCP) is designed to be a bidirectional, ordered, and reliable data transmission protocol between two end points (programs). In this context, the term reliable means that it will retransmit the packets if it gets lost in the middle. TCP guarantees the reliability by sending back Acknowledgment (ACK) packets back for a single or a range of packets received from the peer.

This goes same for the control signals such as termination request/response. RFC 793 defines the TIME-WAIT state to be as follows:

TIME-WAIT - represents waiting for enough time to pass to be sure the remote TCP received the acknowledgment of its connection termination request.

See the following TCP state diagram: 

alt text

TCP is a bidirectional communication protocol, so when the connection is established, there is not a difference between the client and the server. Also, either one can call quits, and both peers needs to agree on closing to fully close an established TCP connection.

Let's call the first one to call the quits as the active closer, and the other peer the passive closer. When the active closer sends FIN, the state goes to FIN-WAIT-1. Then it receives an ACK for the sent FIN and the state goes to FIN-WAIT-2. Once it receives FIN also from the passive closer, the active closer sends the ACK to the FIN and the state goes to TIME-WAIT. In case the passive closer did not received the ACK to the second FIN, it will retransmit the FIN packet.

RFC 793 sets the TIME-OUT to be twice the Maximum Segment Lifetime, or 2MSL. Since MSL, the maximum time a packet can wander around Internet, is set to 2 minutes, 2MSL is 4 minutes. Since there is no ACK to an ACK, the active closer can't do anything but to wait 4 minutes if it adheres to the TCP/IP protocol correctly, just in case the passive sender has not received the ACK to its FIN (theoretically).


[1]Tanenbaum, A. 1996. Computer networks. Upper Saddle River, N.J.: Prentice Hall PTR.

Saturday, August 10, 2013

Find your current location using your Browser - HTML 5

Since i have posted some WSO2 related posts in my recent past blogs, I thought of writing something in diffident context. As most of you know, HTML 5 supports for the Geo Location finder.

This blog can be answer to servaral question such like,
[1]How To Use HTML5 GeoLocation API With Google Maps
[2] How to locate my location using html5 compatible browser
[3] Locate me using html 5

So lets make use of it and develop small HTML web site to identify where are we ;)

As a prerequisite you have to obtain the key from Google in order to activate Google API.
Please refer Google Maps JavaScript API v3 to obtain more information about it.

Lets step into the code and see what is happening underneath...
In line 12 of the code snippet, I have configured the Google API with key in your case you have to replace with your Toke Key you have obtained with Google.

Immediately after this page is loaded, I am calling "getLocation()" using body onload event. In getLocation method (line 17) I am making use of HTML5 Geolocation API to identify my current location. I have set the google.maps.Marker with detected latitude and longitude to configured the Google map that is displayed bellow.

Friday, August 9, 2013

JMS Messagen Store and JMS Message Processor Behavior - WSO2 ESB - Part 3

So why did we meet the EVIL in the my last blog post? Why? yes that is the main reason behind this blog series!!

Now we have to take a deep breath before we dive into the WSO2 ESB and see why this has happened!!

If you carefully study the illustration shown in Figure 1, You will understand whats goes wrong ;)
Figure 1
Anyway, let me take some more time to explain little bit further.
Client sends message to Proxy. "Message Store" persist the message in the message store(JMS Queue). "Message Store" does not persist the message as it is in the JMS Queue. it serializes the message and other information into java serialized object and put it into JMS Queue.When "Message Processor" processes the message, it pulls Messages from JMS Queue and deserializes the java serialized object to further process.

So why did we encounter some exception and other problems in issue 1?
When Message Processor Pull the message from JMS Queue and try to deserialize, Deserilzation process fails since the fetched message is not Serialized by Message Store.

So is that possible to put message into Message Stores's "JMS Queue" ?? NO it is not possible!!!

So whats wrong with Issue 2?
Different JMS listener dose not know how to deserialize the message that fetched from JMS Queue(Message Store)!


Messages that are put into "JMS Queue" by "Message Store" are can be read only by "Message Processor" and "Message Processor" only capable of understanding the messages that are put by "Message Store".


Thursday, August 8, 2013

JMS MessagenStore and JMS Message Processor Behavior - WSO2 ESB - Part 2

I believe that you have referred my last post that elaborates simple use case of "Message Store" and "Message Processor" of WSO2 ESB.

There can be several issues occur in Real time or mistakes made by user
Lets take it one by one!

Issue #1 - Real Time

There can be network loss in between Backend and ESB!! Or Backend can be fail in the real world situation. Nevertheless, these situations are handled by several Enterprise Integration Patterns. And also above situation can be over come with use of Message Store and Message processor. That i have already mentioned in my last post.

Issue #2 - User Error

User error is mainly occur due to lack of knowledge on concept of  "Message Store" and "Message Processor" of WSO2 ESB. As I have noticed several time, Users are making two main issues, that i have mentioned below.

Message Insertion manual in JMS Queue  -Figure 1
As figure-1 illustrated, "Message Store" and "Message Processor" are configured to persist the message and send to Backend. However, User or Client is trying to manually add a message into the give JMS Queue!! 

So lets experiment this and see!

Step 1 - Deactivate the Message Processor and Shutdown the Backend.
Step 2 - Go to you Message Broker (I am using ActiveMQ in this scenario) and try to insert message manually.

Click on "Send To" to insert message manually in ActiveMQ - Figure 3
Add your message into Message body and Click on Send in ActiveMQ - Figure 4
As a result of Step 2, you can notice that in the "JMSMessageStore_Queue"  will be having a message that we inserted now!!!  Hmmmm So far so Good!!!!

Step 3 - Start-up the Backend and Reactivate the "Message Processor" in WSO2 ESB and have a look at the Carbon Log!

What ?? something gone wrong!!!!

Step 4 - Send some messages from client and observe what is happening!!

What ??? Nothing is happening!!!! Hmmmm... Until i explain next situation.... keep on thinking.

Note - you will see the error log In WSO2 ESB 4.6.0. Nonetheless, WSO2 4.7.0 does not show any error log until you enable debug log.  However, end of the day nothing will happen!!!

Fetch the message from JMS Queue using JMS Listener  - Figure 2

Other scenario also quite interesting!! As you see in Figure 2, another different JMS Listener is trying to access the persisted message in our JMS Queue.  So what are you going to do with the message that you got from JMS Queue???? Nothing can do!!! 

Why????? So until i write my next blog keep on thinking!!!!!

JMS Message Store and JMS Message Processor Behavior - WSO2 ESB - Part 1

I have seen lot of users of WSO2 ESB misunderstood the usage of "Message Stores" and "Message Processor" of the WSO2 ESB. In this Blog series, I will explain further about "Under the Hood" functionalists of the "Message Stores" and "Message Processor" to clear the doubts and myths behind those.

Lets take a very simple use case that i have illustrated bellow,

End of the day, Client is sending a message to Backend in this scenario. Nevertheless, under the hood we are persisting message in JMS queue using "Message Store" and sending it to backend using "Message Processor". This will make sure, we never loss any transaction even backend is fail.
When backend is up and running "Message Processor" send the persisted messages to Backend.

Lets try this concept using WSO2 ESB and ActiveMQ as a message broker. Please refer [1] to understand how to configure WSO2 ESB and ActiveMQ. 

As a Backend and Client, I am using WSO2 ESB SimpleStockQuoteService and Axis2 Client. Please note that, these are packed with WSO2 ESB by default. You can find more detail in [2].

Please refer to the Synapse configuration that has been given bellow which demonstrates the concept above. 

 Use the ant command as given bellow in order to invoke the proxy from client.

ant stockquote -Daddurl=http://localhost:9000/services/SimpleStockQuoteService -Dtrpurl=http://localhost:8280/services/MessageReciveProxy -Dmode=placeorder

As result you, can notice in the Backend, there will be transaction has happened. So underneath, our "MessageReciveProxy"  Proxy received the message and persisted in "JMSMessageStore"  Message Store. Thereafter, "SampleMessageForwardingProcessor"  Message Processor took the message from "JMSMessageStore" and send it to Backend for further process.

So far so good! Hmmmm

In my next post I will introduce the evil ;)

Evil Mirror wallpaper from Evil wallpapers