• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

what in reality is a "port"

mcveigh

Diamond Member
I was just thinking of this. OK I've electrical signals going into the computer via a RJ45 jack. what makes information available on port 80 but not 13444?

what is a port? couldn't you recreate what ever data was coming out of a network jack by recording every electrical signal?
 
Sure that is what the software is doing. Translating the electrical data that comes through the port.

Port usage is the decision of the programmer each programming language has set of commands to use the ports.

Let say you want to run ftp, and write your own software. You would be silly to assign to your program to port 378. since this port is assigned by most computers to the printer.

You can assign (by using software) ftp server on your computer using port 56789 but then most of regular client ftp software will not work with it since most ftp software is programmed to use port 21.

Why port 21? Basically a semi-arbitrary decision that was made many years ago by one programmer and then was followed by others.

However you can write your own ftp client that will use port 56789 by default and you would be able to use it with your ftp server

If your question relates to Routers issue it is a different story.

The Router is designed not to let any signal in unless it was requested from your computer. Thus we say all port are closed, in reality it has nothing to do directly with the ports they are ready to work but nothing gets in.
 
I know it's done by software but is it only a number appended to an address?

ie 127.0.0.1:80 or is there more to a port being "open" than a server respondign to a number?
 
It's basically a "Tag" imbedded in the frame/packet that describes to the stack which upper level process to pass the packet to.

Sort of a "Mini-Address:" port 21 goes to FTP, 23 to Telnet, 22 to SSH, 53 to DNS, etc...


Scott


 
If you get some wonderful trinket in FS/FT and you only give you address as: "main street columbia, michigan 22758" you will probably not get your package. So if you tell some random program an ip address to go to without telling it the port number to connect to, you are probably going to be SOL. IANA assigns ports to particular programs. There is probably a list on your machine telling you some of them. These are standards (666 for doom 😀) and every program of that type should follow them (along with their RFC).

Replayiing electrical current sounds tough.
 
There is actually a source port # and a destination port # on every packet. (These are 2 different numbers generally). By convention, every OS hands off a connection request to whatever application called "listen()" with the port # matching the dest port of the connection request (SYN) packet.

The source port and destination port combination along with the IP addresses, make up a 4-tuple that uniquely identifies a connection so the OS can determine which connection each packet belongs to. (Your browser might make 4 simultaneous connections to anandtech web server to download multiple images simultaneously, all with different source ports, but dest port 80).
 
A "port number" in this case is a 16 bit identiifer in the TCP header. The tuple (local addr, local port, foreign addr, foreign port) identifies a particular TCP session.

If you wish to connect to a particular application on a remote host, there is a naming problem of figuring out what TCP port number the application is listening on. The early approach to this problem is to assign particular application protocols "well-known ports" where every system using that protocol is supposed to "know" (see /etc/services on *IX systems, other systems have other kinds of local tables, and some applications just hard-code it) what remote port is used to contact the remote side for the application (usually the server side, on client-initiated sessions). The well-known ports are assigned by the Internet Assigned Numbers Authority (IANA) and the canonical list can be found at http://www.iana.org/assignments/port-numbers

So, for example, the well-known port for FTP's control connection is 21 (FTP is unusual in that it uses multiple TCP connections). So your FTP server (or a super-server like inetd) makes system calls telling your local network stack to listen for TCP sessions destined to port 21 and to send them its way. When your FTP client initiates a connection to a server, with the foreign port set to 21. And thus the two can find each other.

There's nothing compelling anyone to use the well-known port assignments. You can run a FTP daemon on any port, but every client that wants to connect needs to know what that port is, a priori, in order to connect. But if you run it on the standard port, and the client tries to connect to it on the standard port, it Just Works and you the end user don't have to worry about ports at all. This is the benefit of cooperative standards.

"couldn't you recreate what ever data was coming out of a network jack by recording electrical signal?" - this is a very different and separate question. Sure. It's called a replay. You can do this at layer 2 (Ethernet) or layer 3 (IP) or layer 4 (TCP) or higher, also. It works well, is useful for testing, and useful for bad guys too.
 
Back
Top