Page WILL BE tested for compliance with INDUSTRY (not MS-only) standards,
using the free, publicly accessible validator at validator.w3.org
Recommend to StumbleUpon
Material on this page © TK Boyd Sept 2017... but if you want to translate the page, or circulate it on DVD or intranet, I will allow that with some conditions.
This is one page of many in a sequenced series that try to get you connecting things to LANs and the internet with as few tears of frustration as possible. There is an overview page, which is your table of contents to this material.
The page will be most useful to you if you first master the information in the preceding pages. Until those bits explained in them are working, you won't be able to tell if what you're trying to do with the things here are working.
We're going to continue with the EXAMPLE of an IP camera, but, as before, that's just a convenient concrete example. We won't be looking much at camera details.
So far, we have a LAN with an IP cam connected to it. A simple connection-by-cable is fine. If you've gone further, connected the camera to the LAN via WiFi, it matters not to any of the issues here... but it does add one more Thing To Go Wrong.
The camera should be connected to the LAN by a static (local) internet protocol address... "LIPA". I will say "192.168.0.100" in what happens, but EVERY TIME YOU SEE THAT you need to "convert it" to whatever LIPA is "right" for YOUR set up.
The camera is just an example. I will be focused on general issues which will matter whatever device you are trying to connect to LAN or WAN (WAN: another name for "the internet". (An intranet can be on a LAN or the WAN. No special considerations intrude.) Anyone on the LAN can see the images the cam captures. Anyone on the WAN, if you have dealt with the relevant issues, can see the camera images. (You don't need to have done the WAN side of things for what is in this essay to be useful... although you won't need what is here. But doing what is here will prepare the way for putting your device on the WAN inn due course.)
All of these things should have been Got Working during earlier pages in this series of pages.
Now we come to "ports"...
Up until now, I have been funking an issue. The issue of "ports".
I've also left the matter of what kind of device you are connecting a bit vague.
For our needs to date, it has been sufficient to leave things to "the system".
First: The matter of "what kind of device"...
The IP cam, at the level we are on, is actually "a web server".
The electronics and software inside it are set up to accept and process requests from browswers, arriving via LAN or WAN, and to return "stuff", in the right form, that a browser has no trouble putting on your screen for you.
If you are reading this on a computer screen (or web-connected tablet, etc), then you interacted with a web server. This text resides on that web server. It is connected to the WAN. Anyone on the WAN can send a "Please show me the ports essay" request, and the server will... ummm... serve it up to them.
Although the material served up by he IP cam looks different, the process by which it gets to in front of you is exactly the same as the process that gave you this text.
(Why am I laboring this point? Please bear with me... all will be revealed.)
Of course, how IP cams and servers of text work aren't exactly the same. There is a difference which I will come to in a moment. Just remember that "the difference" is irrelevant to the underlying concepts you need to grasp.
The difference: If you are looking at one of the IP cams ** I ** have "put online", then I know exactly where, in GPS terms, if you like, the actual camera is. I can move it to show a different scene. I pay the electricity bill. I deal with the sort of "make it work" detail that I hope you are learning about from this essay.
On the other hand, I have no idea... not even to a country!... where we would have found the actual physical "box" this web page was fetched from when you asked for it. I sent the "original" off to someone I pay to "put it online", and they take care of supplying "the box", and handling all the tiresome settings. All the things that the first sections of this collection of essays covered.
BOTTOM LINE: As far as "how it works", there is no difference between the way images from my IP cameras reach you and how pages like this from me reach you....
In both cases, a WEB SERVER is attached to the WAN, and it responds with usable material when someone uses a browser (e.g. Firefox) to ask for it. (In one cast, the material sent comes from files, in the other from a camera. But there's still a web server involved.)
((Two little digressions...
a) "A web server" can refer to the physical entity, "the box", AND it can refer to the software, the programs running inside the box, to make it serve webpage stuff to browsers which have sent requests.
b) You could, if you wished, set up a "box" in your home which would serve pages like this. (or anything else that can be put into HTML, for that matter. There's even free software for that.)
End of "Two little diversions"))
Hang in there... we WILL get to "services" and ports eventually... but first ANOTHER idea to grasp...
I've talked a lot about "web servers". They "serve" stuff across LANs and the internet.
There are LOTS of things that "serve stuff", in a general sense, across the internet.
Not everyting that "serves stuff across the web" is a "web server".
Not to "people who know".
When "people who know" talk about a web "server", they are talking about something that responds to browser requests (there are other ways to request things across a LAN or WAN). And a "web server" , in the narrow sense, will always respond to requests with some "html", "wrapped" in "an envelope" that says "this is html, for the use of a browser". Not perfect, but perhaps better, would have been to call "web servers" "web PAGE servers".
Besides "web servers", there are...
... and others.
We'll digress briefly to consider just one of those other sorts of server, just as an example of how the SERVICE works.
"FTP" stands for File Transfer Protocol".
To work with an FTP server, you use an app called "an FTP client". It is A LITTLE like a browser. You fire it up. It gives you two windows. One looks at a folder on the hard drive in your PC. The other, initially, looks at nothing.
You take steps to connect to "a folder" of files somewhere on the LAN or WAN. (It is LIKE file sharing, but different!) Those "steps" will probably involve entering a user name and password. (You may not "see" this. The log-on credentials may have been stored "inside" the app. (Setting things up this way is a generous gift to anyone who steals your PC.)
Once you are connected to the online folders, you can "move around" in either window... going "up" to "higher" folders, or "down" to sub-folders. (All subject to various permissions which the system administrator controls.) And you can copy or move files from the local system to the online system, or vice versa.
Of course, you don't "need" an FTP service to download files. You can do it using just a simple browser... IF the person who put the files on the internet set things up that way. You can also, with quite a lot more work by the person who set up the site, UPLOAD files "to the internet", with just a browser. But it isn't the clever way to do it! If the files on the internet are on "an FTP server", and you take the slight trouble to install an FTP client, and learn to use it, it is Just Better. But the details are not important here. Story for another day. Just be aware that there are various "services" out there. (Again "FTP server" may refer to a box or to software. Again, you can pay someone to put files on an FTP server for you, or set up your own box.)
We ARE getting there!
When we put "bbc.co.uk" into the address box on our browser, it took care of adding some things it assumed we meant. What went out was equivalent to...
http://bbc.co.uk:80
The "HT" stands for "Hyper Text"... which is also what it means in "html". The former is "hypertext Transport Protocol" and the latter "hypertext Markup Language".
As discussed earlier, moving stuff between things connected to LANs and/or the internet isn't all about hypertext, not all about "web pages" (more or less the same thing). But when we're using a browser it almost certainly is. (When it ISN'T we take steps to "cancel" the automatic addition of the "http://" part which says "send this off in the form that a web (page) server expects".)
The "80" is a "port"! The thig that we have been so long getting to!
It is an extra element of addressing.
We have LIPAs and WIPAs... and now, in addition, we have ports.
Like the "http", we can usually leave the 80 out. That is the "normal" port for web-page "stuff" (http exchanges of html data)
Now consider a circumstance that can easily arise, even if YOU are not likely to be doing it this week...
Suppose you wanted to set up a computer on your LAN with BOTH a web server and an FTP server running in it, (That's a perfectly reasonable and easy thing to do (when you know enough).)
Whether these serverS would be only for use by people on your LAN (very easy), or for them, PLUS "outsiders" accessing the serverS across the LAN exactly as they might access the IP cam that has been our "basic example" for so long now (quite easy... no extra hurdles) really isn't important to our discussion.
But here's the thing. Let's say that the LIPA of the computer concerned, the ones with the serverS, is 192.168.0.25
And somewhere else, Alice connects and uses her browser to send a request to see a webpage. And Bob, on yet another computer, uses an FTP client to ask for a file. If they are one the same LAN as the computer with the serverS, they will send their requests to 192.168.0.25.
Fine. But when the requests get to 192.168.0.25, how does it know which app to send the request to?
That's where PORTS come in! (Although the "envelope" the request comes in helps, too.)
The request for the web page will have :80 on the end of it, whether Alice typed it out, or just left it to her browser to add the ":80".
80 is the "ordinary" port for http/html
Bob's request will have had a :21 tacked on to the end of it 21 is the "ordinary" port for FTP.
So the two requests will arrive at the computer on 192.168.0.25... and, inside it, one has to go to the web server software and the other to the FTP server software.
No problem! The port specification tells the PC where each request should go. Hurrah. Problem solved. But there's more!
What if the requests are coming from outside the LAN? The requesting computers will both hae sent their requests to the WAN side of the serving computer's modem/router/switch. There's just one WIPA for that. The external computers, Alice's and Bob's, have no way of knowing the LIPAs for the PCs on the LAN which have... i) the web server, and ii) the FTP server.
The solution lies in the fact that the requests specified a port.
Inside the modem/router/switch, there is a table, the "NAT", set up by the LAN admininstrator, which says "If something's for port 80, send it to the PC at (LIPA of the web serving PC)". And another rule in the Network Address Table says "If the request is for port 21, send the request to (LIPA of the web serving PC)".
When we were only working within a single LAN, just LIPAs would do. (Unless some single P was doing both web serving and FTP serving... which is possible.) But once we extended our wants to include working across the WAN, we were in trouble. To the WAN, all the PCs (and other TCP/IP devices) on a given WIPA appear "at" just one WIPA. Ports, and the NAT, allow people out on the WAN to get to the PCthey need... without even knowing its LIPA!
--------------
That's the "hard stuff" for this essay. The rest of this page is "details"
----
I said that web pages are served from port :80, FTP from port :21. Those are the default ports. I would "reserve" them for their expected uses. And there are other ports generally used by certain services. Avoid them too. However, port numbers can be from 0 to 65535.
If you have control of the software running a server, be it a web server or an FTP server, or some other service, there is usually a way to re-configure the server to serve on a different port.
Let's say that you've altered the web server so that it serves on port 81. And that the PC concerned is on LIPA 192.168.0.100.
Now to fetch GoodPage.htm from the server, you put the following into your browser from any PC on the same LAN: 192.168.0.100:81/GoodPage.htm
If that PC is visible to the WAN at, say, HouseOfFred.com, and the NAT has been set up correctly, you would use HouseOfFred .com:81/GoodPage.htm
With some browsers you need to type the "http://" if you are using a port other than :80.
---
Everyone's circumstances are different, of course, but I suspect most readers of this essay will be in an environment where they can reserve LIPAs and ports for specific usages. Across all the work they do. If ou life is that simple... congratulations! It IS simple, if you can take that approach. But be very, very careful to keep accurate, complete, and up- to- date records of what LIPAs you have assigned to which devices. And of what ports you have allocated to what jobs.
---
If you have been thinking as you've been reading, you may have spotted something.
Let's say you want to have 5 IP cams on your LAN. Let's say you have set each up to use a static IP address. Let's say you've used...
192.168.0.100 192.168.0.101 192.168.0.102 192.168.0.103 192.168.0.104
Now... you could... but I would advise against it... leave all of them serving on the default port for http, port :80. Anyone on the LIPA can get to the camera they want with the LIPA alone. (The browser will supply the :80.)
If the cameras are to be accessible from "outside", from devices out on the WAN, you will have to assign a port to each camera. Let's say you choose 1100, 1101, 1102, etc. So far so good. And you don't have to change the port the camera serves on. If the address for your modem/router/switch is HouseOfFred.com, then HouseOfFred.com:1100 or HouseOfFred.com:1104 could work, could give you different camera...
That would work, if you put the following rules into your modem/ router/ switch's NAT saying...
If a request for service on port 1100 arrives, send it to 192.168.0.100, PORT 80
If a request for service on port 1101 arrives, send it to 192.168.0.101, PORT 80
If a request for service on port 1102 arrives, send it to 192.168.0.102, PORT 80
... etc.
Personally, I'd avoid that system. You need to allocate a port to each service on the LAN, so that the port can be used with a WAN request to ikndicate which server should be consulted. It isn't hard to tell the server to operate on a non-standard port. It Just Seems Simpler to me if the port used for a given server is The Same, whether you access the server via LAN or WAN.
That's it for now! (I'll try to do a "proper" "wrap up" in due course... or would you rather I get something else out on the web? If you liked this, PLEASE give it a Facebook like, or mention in a forum?
The search engine is not intelligent. It merely seeks the words you specify. It will not do anything sensible with "What does the 'could not compile' error mean?" It will just return references to pages with "what", "does", "could", "not".... etc. It searches only my SheepdogGuides.com pages.
I also offer an alternative search engine (looking only at pages from all of my sites) use the Google Custom search box at the page the link takes you to.
Click here to visit editor's Sheepdog Software freeware, shareware pages..
Homepage of my main site Sheepdogsoftware.co.uk.
To email this page's author/ editor, Tom Boyd.... Contact information.
Page WILL BE tested for compliance with INDUSTRY (not MS-only) standards,
using the free, publicly accessible validator at validator.w3.org
Why does this page cause a script to run? Because of the Google panels, and the code for the search button. Why do I mention the script? Be sure you know all you need to about spyware.
....... P a g e . . . E n d s .....