My Interpretation of localhost and 127.0.0.1

 

Incident

When executing a test, I see the below message 

The target is unreachable, Please make sure your target is up and running

I have multiple Docker images running on my machine.  Most of these images are different products that are bound to run locally.

Debugging and Observations

In this context, I'm using http://127.0.0.1:portNumber as an IP to communicate with an application which is a Docker image.  I see the above said message.

But, I have not mentioned any IP address specifically; and there is no port forward.  This puts me into question -- What's going wrong here?

I use http://localhost:portNumber and try to communicate with a Docker image. Now the test execution does not see the message above said.

I see  a next question in me:

• Isn't localhost and 127.0.0.1 both mean the same on a local box?

Debugging and Interpretation

1. I see the IP address 127.0.0.1 refers to a loopback interface on a local box
2. When TCP/IP sees the IP address which starts with 127, it understands this is a loopback request
• This request does not go out of the local box
• The response to this request is returned to the top TCP/IP layer of the same local box
3. But, the local box does need to have the same and only one IP address, that is 127.0.0.1
4. The IP of the local box can range from 127.0.0.1 to 127.255.255.255 along with the combination of port numbers which can range from 0 to 65535
• 0 is the reserved port number in TCP/IP; it cannot be used
5. localhost is the domain name for the loopback IP address which is 127.x.x.x.
• This also means, the loopback IP of localhost does not necessarily have to be 127.0.0.1 all time
• It can be different
• And, if the port number is used along with the loopback IP address, then 127.0.0.1 can still be used with different port numbers for different applications and its communication
• Are localhost:5555 and localhost:8888 two different applications on the same IP address?
• It looks so! Technically and logically as well it looks okay
• But, using the same IP address with a different port number is a monolith concept, right?
• Apart from the monolith concept, this is not a good approach
• But, for now when running multiple Docker images locally and testing locally, this is a state and transition which is more likely to occur
  
6. Further I see, the application which is binded to the domain name localhost might not necessarily have the IP address 127.0.0.1 always
• The IP can range up to 127.255.255.255
• This indicates me there is a difference between 127.0.0.1 and localhost
• That is, localhost and 127.0.0.1 does not mean one and the same every time
7. I see there should be binding here to the local box's domain name -- localhost
• This is a differentiator

Given this context, that is, running multiple Docker images locally and testing within a TCP/IP of a local box,

• I see using localhost [with port number] in the URL is a wise strategy in testing if 127.0,0,1 fails.  

Knowing the exact local IP address with the port number should work.  If this fails, we have an incorrect port number or a problem connecting to the port.  

All these are being spoken in the context of

• A local box
• Communication between the images on a local box.

It is all about which application on the local box has taken [registered] the domain name localhost.  Or, find the exact IP address on the loopback interface along with the port number used by an application

How I'm bringing up the servers and what the configuration includes for the IP address and port numbers, is not to be taken casually. Especially on the local box!

Your Thoughts?

If you see my interpretations are incorrect, kindly help me to learn by commenting on this blog post.  We will connect to share and discuss.  I'm open to unlearn and learn!

Note: I have read about the term Small Weight Tests.  These tests have requests and communication which does not go out of the box.  The request and response happen within the box with little or no I/O and CPU operations.

I Transformed In The Heat of Software Testing's Words & Glossary

I'm talking about the words, glossary, and jargon we use in our communication, especially in software testing.

Words in Use

Manual Tester, Manual Testing, QA, QA Automation Testing, Automation Testing, Automate, Automation, Tests, Checks, Verify, Validate, Test Case, and more.

Are these words right or wrong to have in Software Testing's glossary?  I want to see beyond right and wrong.  I will share my learning on this in a different blog post.

Then

When I started my career, I advocated for using the appropriate words and glossary when talking about Software Testing.  I was in this state of mind. I continued in it.

The information on the web for Software Testing was minimal and not abundant as it is today.  I observed practitioners questioning, debating, arguing, and challenging the words and glossary used in Software Testing.  I see, it is good that this scrutiny happened.

It took me years to come out of it and realize what I should be focusing on.

Eventually, I realized it is not changing; it continued and continuing.  I changed. I transformed.  I'm evolving!

Now

Today as well, I see practitioners questioning, debating, and challenging the same words and glossary.  Is this a need?  Yes, it is a need.  Who else will do it if we do not do it?

But, how do I do it now?  I do not discuss it with all and everywhere I see a discussion and opportunity.

Today,

• I listen to people as I did
• I understand what they mean by the words and glossary used in the discussion
• I take an opportunity to trade and introduce the word in discussion in a light way
• I see the other side interprets it as I interpret their word
• We mutually agree on what is expected and to be delivered
• I will move on to continue our discussion and accomplish what we have to
• How often do I do this?
• I choose when to do it
• But I keep the happening calm and a delightful conversing

I'm not stuck or getting into a discussion on words and glossary as I did.

I'm watchful about what I use in discussion and testing delivery.  With my fellow software test engineers on the team, I share my insights, discuss and focus on our work.  I do not enforce or impose anything.  But, I always welcome questioning and challening me.

This has brought me calm, peace, energy, and time for what should I be learning and doing.

Do I ask other fellow practitioners to do the same?  I will not get into this thought.  Let one do what one wants to do.  I converse and discuss if I have any questions and it makes me curious. I move on!

As a practitioner, I know, it is important that I speak up for my craft's and subject's words and glossary.  I introduce it in a light way.  If one is interested, I will be asked about it.

Change in the self is a first progress and I feel peace with it.