Talk:Port (computer networking)/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Ports Analogy

A lot of the people I explain ports to don't really it get it unless I give them some kind of analogy. I find this one quite effective but I'd like some input before I put it on the main article.


"Think of IP addresses and ports as a block of flats, or a university hall of residence. The IP address relates to the address of the actual block of flats as a whole, and the port number relates to the flat number within the block. If a letter (A data packet) is sent to the flats (IP) without a flat number (Port number) on it then nobody knows who it is for (which service it is for). In order for the delivery to work, the sender needs to include a flat number along with the address of the flats to insure the letter gets to the right destination."

Noopectro 17:58, 28 March 2007 (UTC)

Common Ports

List of common ports? Seems relevant to me. If no objections, will add some ports from IANA published list (only ones in common usage by What happens when one system has several IP's?

Each IP can be used or use the same port numbers?

Will those ports be different for different IP's?

I guess both answers are "yes".

Do not forget that an ENDPOINT of a communication link is still a Sockets that consists of a Port AND an IP adress —Preceding unsigned comment added by 87.159.110.4 (talk) 09:37, 24 January 2008 (UTC)

Not all transport layers use network ports

The article says

Not all transport layers use network ports; for example, although UDP and TCP use ports, ICMP does not.

However ICMP does not belong to the tranport layer. How can we rephrase this ? —Preceding unsigned comment added by 82.229.209.33 (talk) 13:51, 7 January 2008 (UTC)

Copy edit request

Kbrose added a copy edit request on 31 July 2008. Edit comment reads, "articles used poor, imprecise, conflicting language and needs copy editing." I saw the copy edit tag at the top of the article and prepared myself for a rough ride. I was surprised to find a generally well-written and well-organized article. I'm tempted to remove the copy edit request but want to give Kbrose an opportunity here to get more specific about what exactly needs editing before taking that step. --Kvng (talk) 17:43, 27 August 2008 (UTC)

Requested move

The following is a closed discussion of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the proposal was No move Parsecboy (talk) 13:40, 8 December 2008 (UTC)


TCP and UDP portPort (networking) — The common name of the subject in networking parlance is simply "port". — —/Mendaliv//Δ's/ 19:28, 3 December 2008 (UTC)

Survey

Feel free to state your position on the renaming proposal by beginning a new line in this section with *'''Support''' or *'''Oppose''', then sign your comment with ~~~~. Since polling is not a substitute for discussion, please explain your reasons, taking into account Wikipedia's naming conventions.
  • Oppose: This article specifically deals with "ports" in the context of the Internet Protocol (mainly, but not exclusively, TCP and UDP). "Ports (networking)" is to general and vague a title for this IMHO. If we were to change it I'd suggest something more like "IP port" (cf. IP address). Letdorf (talk) 11:37, 5 December 2008 (UTC).
  • Oppose: "Port" in networking is commonly also used to refer to a physical connection as in "Ethernet port". "UDP and TCP ports" is arguably a mouth full but that's exactly what's described here. "IP port" may be acceptable but a (technical) argument could be maked that the ports are more closely affiliated with UDP and TCP than with IP. --Kvng (talk) 03:00, 7 December 2008 (UTC)

Discussion

Any additional comments:
The above discussion is preserved as an archive of the proposal. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Thanks

Great article, thank you for it. It is finally clearly explained that the port is used between transport layer and service. Doru001 (talk) 14:15, 26 January 2009 (UTC) Yes, the last person who rewrote the article is a genius. The explanations will be clear to anyone one cares to consult this entry. BAlfson (talk) 03:11, 5 February 2009 (UTC)

old

"Note that not all transport layers use network ports; for example, although UDP and TCP use ports, ICMP does not." - Thought ICMP was a network layer protocol

e-mail server example

A server used for sending and receiving e-mail provides both an SMTP service (for sending) and a POP3 service (for receiving).

I found this confusing. An e-mail server sends e-mail contents to the client, but this amounts to receiving e-mail from the point of view of the user. Similarly, it receives content from the client, but this is part of sending e-mail. In addition, it sends outgoing messages to and receives incoming messages from the outside world. So "receiving" could plausibly mean any of three things. 72.75.67.226 (talk) 03:15, 3 October 2009 (UTC)

You are quite correct about your observation. I have rewritten that paragraph to address your concern. Thank you. Kbrose (talk) 03:34, 3 October 2009 (UTC)

port scanning

"Because different services commonly listen on different port numbers, the practice of attempting to connect in sequence to a wide range of **services** on a single computer is commonly known as port scanning"

Is **services** supposed to be 'ports'?

Yes. There is a service behind each port but changing services to ports is an improvement. I've made the change. --Kvng (talk) 23:19, 6 May 2010 (UTC)

New name

I assume that Port number would be preferred over the current title (Port number (Internet socket)). Port number redirects here. I've requested speedy deletion of the Port number redirect page. --Kvng (talk) 18:13, 31 August 2010 (UTC)

Well, that's certainly a possibility, which I had contemplated as well. Port number could be ambiguous, switches or routers have port numbers as well. So, I figured leave 'port number' as redirect in case someone disputes primary usage and wants a disambiguation page. Kbrose (talk) 18:41, 31 August 2010 (UTC)
One can always create Port number (disambiguation) if the need arises. --Kvng (talk) 19:58, 31 August 2010 (UTC)

Dynamic ports

Is dynamic port a synonym for ephemeral port. The article says "The dynamic or private ports are those from 49152 through 65535. One common use is for ephemeral ports." what are the other uses? --Kvng (talk) 17:25, 13 March 2011 (UTC)

Question / Idea

I have an idea about a feature that would change how the internet worked.

I propose that DNS have resource record types such as: porthttp,porthttps,portsmtp,portsmtps,portimap,portimaps,portpop3,portpop3s,portftp,portftps,etc...

I appears to me that such a move would change the way the world relies on IP addresses, since we appear to be running out. If you think how many servers there are in the world that have static IP addresses that only host one web page or even one service.

It seems like it would be fairly easy to implement a record type lookup to determine what port a website is using. The same thing could be accomplished for looking up what port a mail server is using. Yes the web browsers of the world could be adapted to do a ip and port lookup.

SSL Certificates could be adapted to include both the domain name and port.

DNS record types could be created and used to register what port a webpage is on.

For example: My webpage would have two DNS records. Record Type "A" host record, www.example.com = 127.0.0.1 Record Type "porthttp" port record, www.example.com = 80

This type of resource lookup would allow the internet to host a website or service on which ever port they wanted and would prevent the world from relying on common ports as the answer of where am I going to put my service.

Think about this. Currently one static IP address can only host one website service on a single static IP address. Routing and NAT take care of this. The only problem is there is no DNS record to lookup a port for the expected service. If a single IP address can have 65535 ports then a single IP NAT address could host 65535 websites on 65535 different ports. All is need is the ability to find the port that the http service is located on.

I also see this as a chance to solve the world's problem with ISP's blocking commonly used ports.

I don't have the programming skills to do the work, but if the idea was communicated to the world, the right people could make it happen.

09:55, 28 July 2011 (UTC) — Preceding unsigned comment added by 68.106.179.249 (talk)

Port conflict

The limitation that only one program can listen to a IP:port derives from the BSD socket implementation. There is no port "conflict" when you bind to different IPs on the same port. For example you can have multiple HTTPS virtual sites on different IPs on the same machine, on the same interface, and on the same port. --Mircea.Vutcovici (talk) 02:30, 9 October 2011 (UTC)

It's important to explain WHY ports exist

I added an explanation into this article several years ago, but someone deleted it. That makes no sense because right now, the article doesn't explain WHY ports are necessary. For laypersons who don't understand computer science, ports (along with most computer science concepts) are totally mysterious, and the article as it stands doesn't help them understand ports one bit. The article should have an explanation that ports are used to uniquely identify different programs running on computers linked to a network so that multiple programs can multiplex multiple virtual connections over the physical network connection; otherwise, only one program could open a connection over the physical layer at any particular time (since the only unique identifier would be the IP address itself). (The obvious analogy is to the old bulletin board systems, where a single monolithic client had full control over a PSTN phone line and talked directly to the BBS at the other end.) Any objections? --Coolcaesar (talk) 08:27, 4 August 2011 (UTC)

Indeed, the article needs help. One issue is that you added this to the lead section without any source. It was then changed also without any source to describe "well known" ports. I do think it is important to mention that port numbers are essentially a form of multiplexing, but the current description of this does not seem right either. Ports are used in peer-to-peer protocols as well as client-server, and on both single tasking and multitasking operating systems. But multiplexing is only needed if there are multiple connections (even if only on one side). Generally the best approach is to add information in the body with citations, and then have the summary in the lead. W Nowicki (talk) 17:40, 4 August 2011 (UTC)

I, for one, would appreciate that information being added back; I came here doing personal study to supplement a class in networking, and thought the article jumped right in without recognizing that the reader might need that "layperson" description. Please consider it. — Preceding unsigned comment added by 134.126.20.126 (talk) 13:49, 9 October 2012 (UTC)

TCP/IP bias

A port is associated with

SHOULD READ

In the case of TCP/IP, a port is associated with

or some such

G. Robert Shiplett 13:07, 10 January 2013 (UTC).

Improvement

Can someone tell me what the improvement is in this change. I don't see it. ~KvnG

no redirection and https — Preceding unsigned comment added by 2.86.131.52 (talk) 19:49, 27 January 2014 (UTC)

Globally unique

The short paragraph in the lede about some combination(s) of IP address and port needing to be 'globally unique' is drifting off into incomprehensibility, IMHO. I see it was added in [this edit under the comment, "Restating this for clarity." When people feel they need to re-state things within an article, and begin doing so with the WP:MoS violating construct "Note that..." you know it ain't gonna be good, IMHO. The whole precept of the paragraph is flawed, as every IP address is globally unique anyway, so of course anything that includes it will be too: Port numbers are not there to stop the internet getting muddled between ambiguous addresses. A web server could be dealing with thousands of simultaneous requests all on port 80: the 80 isn't there to stop the server getting muddled between all the simultaneous requests as they are all for port 80. There is no benefit in directly addressing our poor benighted readers to tell to 'note' something that is neither true no helpful, nor to my knowledge ever emphasised by textbooks on this topic. What is unique is that there should be only one process bound to any one TCP port. But even that gets hard to explain as computers can have multiple network cards (NICs), or multiple IP addresses assigned to the same NIC, and anyway even without that, you can have multiple UDP processes sharing the same IP and port. It isn't one of the main problems; people don't misunderstand ports because they try to bind multiple processes incorrectly - it never happens as the binding is taken care of by software that would just throw an error if you tried. Therefore, I think it should come out of the lede, and so I have removed it. --Nigelj (talk) 13:09, 20 October 2014 (UTC)

Ports provide a multiplexing service on each server-side port number

"In the client-server model of application architecture, ports are used to provide a multiplexing service on each server-side port number that network clients connect to for service initiation, after which communication can be reestablished on other connection-specific port numbers."

What does that even mean? I found this in the lede. I don't know what the author here is trying to say. The WP:LEDE is meant to summarise the main points of the article, and as far as I can see, nowhere else in the article is multiplexing mentioned, nor this extra service that ports are being alleged to provide. If I have missed it, please can someone provide a reference and a clearer statement of this extra feature. In the meantime, I have removed this text from the lede. --Nigelj (talk) 13:16, 20 October 2014 (UTC)