Sheepdog Software HOME  »  ArduServer & ArduSimpSrv HOME
-d- Bookmark this on Delicious   Recommend to StumbleUpon

Connecting Servers to the Internet

Introduction, basic concepts, for the hobbyist. IP Address, DNS, etc

What this page tries to do:

This page is meant to be a general introduction to concepts you will need to master to connect an ArduServer, ArduSimpSrv or FarWatch computer to the internet. Overcoming the details, in practice, is covered elsewhere.


Connections to the internet- General considerations-

Serve a LAN/ Serve the Internet. See the tutorial I just mentioned for a more thorough explanation. In a hasty nutshell...

If you ask Google to find places to buy an Arduino, you will be using client software (your web browser, e.g. Firefox) to access a web server, Google.

Not every server is a web server. To be a web server, something must not only respond to requests from clients, but it must respond with data "wrapped up" (formatted) according to some "extra" rules. Those rules explain why it (hardly) matters which web browser you use.

In your study of servers and clients, you will gradually become used to the fact that when we speak of a server or of a client, we will sometimes be speaking of hardware, and sometimes be speaking of the software which makes the hardware do the serving or be the client asking for service.

Servers and clients have to be connected.

It is perfectly possible to have quite separate server software and client software co-existing in a single PC. You can have your web browser and a wordprocessor running at the same time, can't you? While they will rarely "talk" to one another, there are client/ server situations which do arise in a single PC. (Not every example of one program "talking" to another is an example of client/ server operation, though.)

But it is more usual, when speaking of client/ server work, that the two pieces of software are in two separate bits of hardware. And thus they need connecting. (When the client and the server were in one PC, they still needed "connecting", via the operating system. But the "connection" was more abstract, harder to perceive.)

Today, the usual connection between client and server is TCP/IP, which is more general that "ethernet" or "LAN" or "world wide web". All of those may well involve or carry TCP/IP connections, though.

And you can have TCP/IP without having HTML. TCP/IP is a lower level concept. HTML does usually travel from place to place over TCP/IP links.

On ordinary local area networks (LANs), we use ethernet or WiFi technology to connect devices. That is the hardware level connection. TCP/IP, for most of our purposes, doesn't care what hardware is being used to connect the devices.

Consider a non-client/ server "connection" between two computers: File sharing.

If I have files on "Computer A" shared with "Computer B", then I can read those files from either machine. If I read them into B from A, the process will probably use TCP/IP. It will make no difference at all to what I do whether the machines are connected with wires or wirelessly.

One of the great foundation stones laid down at the dawn of all of this was the "IP Address" (The link will take you to Wikipedia's article, in a new tab or window).

All you need to know for now is that IP addresses look like...

192.168.0.250

or... not so very different, just another example...

86.25.177.101

IP addresses consist of numbers between 0 and 255 (inclusive), separated by periods. To date, IP addresses made up of four such numbers have generally sufficed. A new "standard" IP address is coming into use. The modern one has six numbers from 0-255 separated by periods.

Not all IP addresses are created equal. The way the system is set up, an IP address starting "192.168.0." will take you to someplace on your LAN... maybe. (If there is no device with the address in question, you will just be told "unreachable", or somesuch.) There are probably millions of devices, certainly thousands, "at" 192.168.0.250.... but this isn't a problem, because there is only one such device on any given (working) LAN. (One way to make your LAN buggy is to somehow attach two devices both using the same IP (or MAC) address.)

The other address given above, will take you to just one place in the whole world. There is only one "86.25.177.101". At the time I wrote this, it was the modem I have attached to the internet. However, the assignment of my modem to that IP address is not within my control. By the time you read this, my ISP may have given me a different IP address, and given 86.25.177.101 to someone else.

Hold those IP address thoughts.... we will come back to them.

When you go off to your favorite web page, you don't worry about the IP address for it, do you? You use a URL, aka URI.

It is comprised of a domain name, e.g. bbc.co.uk, and an optional path specification, e.g. radio3. (Enter just bbc.co.uk, and the server there will send you the page the administrators at bbc.co.uk have decided to send anyone who queries the server without specifying a page. Enter bbc.co.uk/radio3, and the server uses the material to the right of the first "/" to guide it in knowing what you wanted returned.

We are spared having to use IP addresses because of the DNS... the "Domain Name System". Think of it as a telephone book for internet TCP/IP connections. If I knew the IP address for the BBC, I could use that, plus /radio3. But I don't. And for some of the things I want to access, the IP address changes from time to time. For my ArduServers and ArduSimpSrvs, the IP address changes. So it is really nice that DNS servers exist. As long as users of URLs keeps the DNS appraised of the current IP addresses of their services, the DNS can, behind the scenes as far as ordinary users are concerned, tell anyone wanting to contact a particular service what the current IP address is for that service.

See why I told you not to let IP addresses out of your mind before now?

Think about it hard enough, and you will see that there can be only one owner... in the world... of the domain name "bbc.co.uk". Happily, you can buy ownership of your own domain names. Even a .com name only costs about $10 per year. I use 1and1.com (and 1and1.co.uk) as my agent for buying the domain names I own.

Owning a domain name is a good first step. There's no point in owning it, though, if the DNS doesn't know where to send people who know the domain name, and there's no place to send them unless you own, or rent the use of, a server.

You can connect an ArduServer to the internet. You can connect fancier web servers to the internet. You can rent the use of a web server from many people; I use 1and1.com and 1and1.co.uk.

The IP address of your server will depend on several things. If you are renting the use of a web server, the company you rent from usually takes care of making sure that the DNS always has the right IP address for the pages "at" your URL.

Some people have "static IP addresses". If you are one of those lucky people, you will know (from your bill) and will know more than I can tell you.

Most of us do not have static IP addresses. We have a connection to the internet, thought which we send out requests, e.g. a question to Google, and through which we get the answers back.

When you are ready to take the next step, to join the ranks of Google, and offer a server to which clients can send requests, you start to need to have your IP address known to the DNS.

And there's a really clever answer to this problem. There are various companies out there willing to help you. I use "Dyn.com" (They used to be called Dyndns.com). And here's how it works...

I have an account with them. And, where I have my equipment, one piece of that checks the IP address currently allocated to me by my ISP. If that address has changed since the last check, my equipment gets in touch with Dyn.com and says "Please tell the DNS that the IP address for Tom's server has changed. It is now at..." Cunning! And it Works!

That's "it"... almost. I give you help with the details of Doing It in various places. I hope that overview will help you understand the details, as they arises.

There is one general matter which I haven't addressed so far.

For the people likely to read this, the device they want to connect as a server on the internet will not be directly connected to the internet. It will be on a LAN, with a local address like 192.168.0.250... but there will be other devices on the LAN, too. Everything on the LAN will connect to the internet through a router and a modem (often the two are inside a single box). When, say, computer "A" asks the internet for Google results for "buy arduino" at almost the same time as computer "B" asks "do I have any email?", the router takes care of sending both requests out onto the internet, and routing (hence the name) the separate responses to computer "A" and computer "B", as appropriate.

That's all well and good for things initiated within the LAN, because when the answers come back, "inside" the answer is data about who asked the question giving rise to the arriving answer.

However, when a client outside your LAN makes a request over the internet, it can't say "send this question to the device on the LAN at 192.168.0.250". Happily, we have "ports" to save the day. A "port" isn't, except in the broadest, figurative, terms, "ports" in the sense of "USB port", or "serial port". Rather, they are more like a parameter on a subroutine call. When the request for service arrives, it will arrive with a port number. ALL TCP/IP client software includes a "port to be used" datum with the request for service. ALL of the requests to your domain name arrive at the same place... the "outside" side of your router. When you are just getting started, you may not even notice it, but requests for a web server are ordinarily sent with the "port" setting set at 80. And when you set up a web server inside your LAN, you normally tell the router that requests bearing the "port 80" setting should be sent to the web server hardware which you have attached at, say, 192.168.0.250. But it isn't set in stone that the client should attach "80" as the port number. Nor that your router should only handle requests bearing "port=80".

As long as people who want to use your service know what port to specify when they send their request for service, one router and LAN can host multiple services. At the moment, for instance, my router at mon7nc.dyndns.org has a web server on port 80. (That is my FarWatch server... it will tell you about recent and current weather at a place in southern England.) If you send a request to mon7nc.dyndns.org over port 81, however, you will get a web server running in my first ArduServer. You do that by putting http://mon7nc.dyndns.org:81 into your ordinary web browser, by the way. If you send a TCP/IP request to mon7nc.dyndns.org:5202 with an ordinary web browser, you won't get a sensible result. But if you send a request marked for the attention of that port with the client software I give away for free, you will get a sensible answer from the ArduSimpSrv on the same LAN as my web server and my first ArduServer.

A lot to take in, I know. I once didn't understand it, and worked hard to get to where I am now. But I am self taught. It isn't rocket science. All of the pieces have a rather beautiful simplicity. It is just a bit of a challenge to fit it all together in your mind!

Further reading....

That will, I hope, have taken you forward in a quest to connect a server to the internet. For details and specifics of some instances of servers on the internet, I commend to you my ArduServers (easy... if you are an Arduinophile) , or my FarWatch system (do-able... for free... if you are a Windows user, and many of the points will help Linux people, too.)



Contact this page's editor, Tom Boyd


Valid HTML 4.01 Transitional Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org. An early draft of the page was valid apart from several things inside the code to embed the video clip of the ocelots.

- - - Page ends - - -