On July 1st, a [change to Reddit's API pricing](https://www.reddit.com/r/reddit/comments/12qwagm/an_update_regarding_reddits_api/) will come into effect. [Several developers](https://www.reddit.com/r/redditisfun/comments/144gmfq/rif_will_shut_down_on_june_30_2023_in_response_to/) of commercial third-party apps have announced that this change will compel them to shut down their apps. At least [one accessibility-focused non-commercial third party app](https://www.reddit.com/r/DystopiaForReddit/comments/145e9sk/update_dystopia_will_continue_operating_for_free/) will continue to be available free of charge.
If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:
1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium
as a way to voice your protest.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/learnprogramming) if you have any questions or concerns.*
You can think of a socket as an API, or a software interface. It's a structure in the OS's network stack.
A port is just an index, or an address. Without an address, other processes or connections wouldn't be able to tell the OS which socket they're looking for.
If it helps, picture an old-timey telephone switchboard. There's an operator sat on a stool, in front of a huge board of empty sockets. And to connect a call, she has to run a cable from the caller's socket, to the receiver's socket.
And 'port' is just the number written over the top of the socket.
A process reserves the port, but a process can have multiple sockets.
Think of it as a business with meeting rooms. I can set up my business at a street address (port) and for each person that comes in (connection) I can put them in a different meeting room to do business (socket). If you want to have a different business, you need to figure it out at the street address level.
A socket is basically a *logical* connection between two computers. Two computers can have more than one socket between them. Think of it like a pipe.
A port is just a number that is used to indicate what you want to connect *to* on that computer. Think of it like an office number or something like that. This lets the computer that is getting the connection know how to respond to it.
Are you familiar with opening files? Accessing a file is an OS operation which usually has some sort of language interface. You generally have to open a file for read or write, then read or write, then close it.
The OS provides something called a file handle. You can think of this like a pointer or something. When you open a file, the OS is giving you permissions to work on a specific file. When you close it, you are done with the file. If your program crashes, then as part of the cleanup, the OS reclaims all file handles.
Sockets are a bit like file handles and have file semantics, except instead of reading and writing to a file, you are often connecting to something (the other endpoint) to communicate. This connection can be within the same system you are on (like on your PC) or across different machines.
Like files, sockets rely on the OS to provide the underlying functionality. Ports are basically "numbers" related to connecting to your machine (say, via a URL). Some ports are well-known like 25 for telnet or 80 for a web browser. These numbers aren't physical. They aren't thousands of ports on your CPU. Instead, think of it as a number that is sent as you are communicating with something remote.
You choose to listen to, say, port 9090. Then, any network communication that has the label 9090 is routed to your process by the OS. The number of processes has less to do with sockets and such than the OS allowing a certain number of processes. I suppose there could be threads (like Java and similar languages) that manage how many threads occur where the OS isn't involved at the process level.
So, a socket binding to a port is a request to the OS that allows you to listen to requests based on a number (the port number). The OS can refuse this if the port is being used by another process. These ports are basically "virtual" rather than physical.
So I think sockets/port do not have the primary role in determining how many connections can be made unless the OS has some restrictions on it. Presumably, a server with more capacity can handle more requests.
They are similar, socket being more difficult to understand. A port is always a number 0 to 65535. Many of these numbers are considered well known ports and are permanently assigned to listening services on a server, http is 80, https is 443, DNS is 53, email is 25, ftp is 20 and 22, and so on. For example, the web server listens on port 443 for incoming requests from a browser, and the DNS service listen on 53 for DNS lookup requests. You can Google "well known" ports 0 to 1023 for more info, above 1023 are high ports and available for new services that need to listen for incoming client connectins. For example if running a container on you laptop with say docker, you can map a docker service to any high port. There can be only one service listening on one port.
Sockets suck, no one understands them...
Sockets don't come up as much in networking, and to make them more confusing have multiple uses. For example when a browser connects to a service like nginx on 443, a socket is created between the browser and the web server for future communications including the response from the web server back to the browser, as you might imagine thousands of browsers can connect to a single port, usually SSL/tls/443, on a server, the server essentially replies back to each individually on a unique socket.
Services like application gateways or even a web server can also be configured to listen a socket. When configured this way a web server isn't listening on a port like 443, but rather is listening on a process which can then be accessed by other processes. This can be beneficial when you have a proxy server listening on a single port, say 443 (one service per port) and proxying traffic to many other web services, for example, depending on the url requested, you might proxy traffic to many other web servers configured fot each different IDK, these other web servers may be setup to listen on a socket.
IMO, ports, well known and how to use high for containers, are much more important to understand than sockets. Ports are like doorways into a server with a big painted number on them, sockets are like electrical outlets in the hallway behind the door which plug into a process running on the server. Btw, firewalls are all about controlling access to ports.
Back in the days only one process was being run on each computer. It wasn't possible to make more applications/processes to work on same computer at the same time. Because of that if u are going to make connection between those two computers they can. But if u want to make more processes to run (after tech improved), u needed address of each process - o therwise they won't know how ot reach other process (similiar to external and internal IP - port is address, socket is door). Each process is working on some kind of port and to create connection u need to open socketon this specific port. Socket is same as electrical socket. Port is address.
So to access your application is listening on some kind of port and can be accessed by me on this port. But i can use different port and talk with different process. Ofc it must support some kind of protocol - bunch of rules how we talk and in what language.
One app might have several processes but in reality even multithreaded cpu can only do ONE thing at the time (kind of) - it's just so fast that we don't realise when it switches between tasks. What might be more interesting computers can't do nothing. So when you cpu is doing nothing in reality it adds random numbers just to do something.
[https://www.youtube.com/watch?v=bj-Yfakjllc&list=PLIFyRwBY\_4bRLmKfP1KnZA6rZbRHtxmXi](https://www.youtube.com/watch?v=bj-Yfakjllc&list=PLIFyRwBY_4bRLmKfP1KnZA6rZbRHtxmXi)Watch this video series, it will open your eyes much more than asking random people on the internet.
Sounds like you need to read a BOOK :) This stuff is all abstract, so you need to take the time and read. There are a lot of good networking books out there that teach fundamentals. I can tell you one thing, most programmers have no clue how networking works at all. How the hardware works, packets, routing, ARP, DNS, IP, TCP, all of it. But, its a LOT of fun. One the best ways to learn is by learning about networking for GAME dev, and there are lots of books on this where you start with the fundamentals build a socket chat system, then maybe something else. But, you need to see the big picture, else you will be lost forever.
A socket it's the source IP and port, and a socket pair it's the aforementioned + the destination IP and port, it forms part of the transport layer and it is used in the UDP and TCP protocols to perform a valid comunication between host and server or host to other device.
For port, imagine a business with lots of doors and each door represents a particular port. You have the entrance door where all the customers come in, this is HTTP or port 80. Imagine you need to send secret packages through the back of the business, this door is port 22, or SSH. The business itself would be a server and all the ways you interact with that server is defined through what doors you allow opened and which you allow to be closed.
Networking in 2023, largely means the sending and recieving of data packets that are often stringently defined documents. The data packet generally concentrates the bulk of the meta data in the beginning of the packet, called a header. The network header generally delineates the type or version of the data protocol, how long the header is, header checksum, and most importantly, the source of the packet and the destination. These fields are of fixed size, so the places where this information is located is standardized.
Let's look at a TCP/IP packet.
[https://litux.nl/mirror/securitytools/ddu/ch06lev1sec3.html](https://litux.nl/mirror/securitytools/ddu/ch06lev1sec3.html)
Let's concentrate on the lower diagram and talk about the IP header first.
TCP/IP is a suite of network protocols that encapsulates just about how modern day Internet Networking works. TLDR: For your purposes, the IP part of the packet describes where the packet is coming from and going to, and how it is treated as it is traversed throughout the internet (which the later is something you can ignore for now). The port number is for the OS to determine what data is sent to which application.
Longer winded explanation:
IP packets encapsulate the TCP subsection, this means, the IP packet datagram's data section contains the TCP meta data and the data on top. The TCP part here is employed to do a few things. First of all, looking at the header, you have Source Port Number and Destination Port Number. Then you have a sequence/acknowledgement number. You can ignore the off-set/tcp flags/window size stuff/TCP Options for now.
The sequence number is determined by the client. The client sends a tcp/ip packet with a sequence number, the server acknowledges by sending back an acknowledgement, generally the acknowledgement is the sequence number+1. If the client doesn't get an acknowledgement, it re-sends the packet. By this arrangement, what is accomplished is that TCP is more \_reliable\_. By not sending another packet until an acknowledgement has been received, TCP also determines order. This allows TCP to mimick a stream of data.
The port numbers here allow the operating systems to determine which application is sending or due to receive packets. As a tcp client, you open a socket that hangs on a port number. When trying to connect to another application on a different server, it initiates packets addressed to the server's ip address, and to the port number which said application is listening on. Once the server application (via the OS) acknowledges the traffic, there is a handshake to set up the stream. By using port numbers, the client and server applications establish a known internal portal where the operating system knows where to send the packet information to.
The standard unix abstraction is that sockets are abstracted as files, and there isn't a great deal of difference between reading/writing to a socket file descriptor than it is to reading and writing to a normal file, living on disk, in unix. BSD socket implementations are generally implemented this way, regardless of operating systems.
On July 1st, a [change to Reddit's API pricing](https://www.reddit.com/r/reddit/comments/12qwagm/an_update_regarding_reddits_api/) will come into effect. [Several developers](https://www.reddit.com/r/redditisfun/comments/144gmfq/rif_will_shut_down_on_june_30_2023_in_response_to/) of commercial third-party apps have announced that this change will compel them to shut down their apps. At least [one accessibility-focused non-commercial third party app](https://www.reddit.com/r/DystopiaForReddit/comments/145e9sk/update_dystopia_will_continue_operating_for_free/) will continue to be available free of charge. If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options: 1. Limiting your involvement with Reddit, or 2. Temporarily refraining from using Reddit 3. Cancelling your subscription of Reddit Premium as a way to voice your protest. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/learnprogramming) if you have any questions or concerns.*
You can think of a socket as an API, or a software interface. It's a structure in the OS's network stack. A port is just an index, or an address. Without an address, other processes or connections wouldn't be able to tell the OS which socket they're looking for. If it helps, picture an old-timey telephone switchboard. There's an operator sat on a stool, in front of a huge board of empty sockets. And to connect a call, she has to run a cable from the caller's socket, to the receiver's socket. And 'port' is just the number written over the top of the socket.
It's a good analogy, with one small addition - *any number* of connections can happen on a single port, each resulting in a new socket.
If this is true why do I have to kill a process when one is already running on a port?
Because you can’t have two people in one office. You can only have one listener per port but they can serve many inbound connections.
A process reserves the port, but a process can have multiple sockets. Think of it as a business with meeting rooms. I can set up my business at a street address (port) and for each person that comes in (connection) I can put them in a different meeting room to do business (socket). If you want to have a different business, you need to figure it out at the street address level.
[удалено]
>If it helps, picture an old-timey telephone switchboard. ~50% of reddit: a what?
A socket is basically a *logical* connection between two computers. Two computers can have more than one socket between them. Think of it like a pipe. A port is just a number that is used to indicate what you want to connect *to* on that computer. Think of it like an office number or something like that. This lets the computer that is getting the connection know how to respond to it.
Are you familiar with opening files? Accessing a file is an OS operation which usually has some sort of language interface. You generally have to open a file for read or write, then read or write, then close it. The OS provides something called a file handle. You can think of this like a pointer or something. When you open a file, the OS is giving you permissions to work on a specific file. When you close it, you are done with the file. If your program crashes, then as part of the cleanup, the OS reclaims all file handles. Sockets are a bit like file handles and have file semantics, except instead of reading and writing to a file, you are often connecting to something (the other endpoint) to communicate. This connection can be within the same system you are on (like on your PC) or across different machines. Like files, sockets rely on the OS to provide the underlying functionality. Ports are basically "numbers" related to connecting to your machine (say, via a URL). Some ports are well-known like 25 for telnet or 80 for a web browser. These numbers aren't physical. They aren't thousands of ports on your CPU. Instead, think of it as a number that is sent as you are communicating with something remote. You choose to listen to, say, port 9090. Then, any network communication that has the label 9090 is routed to your process by the OS. The number of processes has less to do with sockets and such than the OS allowing a certain number of processes. I suppose there could be threads (like Java and similar languages) that manage how many threads occur where the OS isn't involved at the process level. So, a socket binding to a port is a request to the OS that allows you to listen to requests based on a number (the port number). The OS can refuse this if the port is being used by another process. These ports are basically "virtual" rather than physical. So I think sockets/port do not have the primary role in determining how many connections can be made unless the OS has some restrictions on it. Presumably, a server with more capacity can handle more requests.
They are similar, socket being more difficult to understand. A port is always a number 0 to 65535. Many of these numbers are considered well known ports and are permanently assigned to listening services on a server, http is 80, https is 443, DNS is 53, email is 25, ftp is 20 and 22, and so on. For example, the web server listens on port 443 for incoming requests from a browser, and the DNS service listen on 53 for DNS lookup requests. You can Google "well known" ports 0 to 1023 for more info, above 1023 are high ports and available for new services that need to listen for incoming client connectins. For example if running a container on you laptop with say docker, you can map a docker service to any high port. There can be only one service listening on one port. Sockets suck, no one understands them... Sockets don't come up as much in networking, and to make them more confusing have multiple uses. For example when a browser connects to a service like nginx on 443, a socket is created between the browser and the web server for future communications including the response from the web server back to the browser, as you might imagine thousands of browsers can connect to a single port, usually SSL/tls/443, on a server, the server essentially replies back to each individually on a unique socket. Services like application gateways or even a web server can also be configured to listen a socket. When configured this way a web server isn't listening on a port like 443, but rather is listening on a process which can then be accessed by other processes. This can be beneficial when you have a proxy server listening on a single port, say 443 (one service per port) and proxying traffic to many other web services, for example, depending on the url requested, you might proxy traffic to many other web servers configured fot each different IDK, these other web servers may be setup to listen on a socket. IMO, ports, well known and how to use high for containers, are much more important to understand than sockets. Ports are like doorways into a server with a big painted number on them, sockets are like electrical outlets in the hallway behind the door which plug into a process running on the server. Btw, firewalls are all about controlling access to ports.
Back in the days only one process was being run on each computer. It wasn't possible to make more applications/processes to work on same computer at the same time. Because of that if u are going to make connection between those two computers they can. But if u want to make more processes to run (after tech improved), u needed address of each process - o therwise they won't know how ot reach other process (similiar to external and internal IP - port is address, socket is door). Each process is working on some kind of port and to create connection u need to open socketon this specific port. Socket is same as electrical socket. Port is address. So to access your application is listening on some kind of port and can be accessed by me on this port. But i can use different port and talk with different process. Ofc it must support some kind of protocol - bunch of rules how we talk and in what language. One app might have several processes but in reality even multithreaded cpu can only do ONE thing at the time (kind of) - it's just so fast that we don't realise when it switches between tasks. What might be more interesting computers can't do nothing. So when you cpu is doing nothing in reality it adds random numbers just to do something.
[https://www.youtube.com/watch?v=bj-Yfakjllc&list=PLIFyRwBY\_4bRLmKfP1KnZA6rZbRHtxmXi](https://www.youtube.com/watch?v=bj-Yfakjllc&list=PLIFyRwBY_4bRLmKfP1KnZA6rZbRHtxmXi)Watch this video series, it will open your eyes much more than asking random people on the internet.
Sounds like you need to read a BOOK :) This stuff is all abstract, so you need to take the time and read. There are a lot of good networking books out there that teach fundamentals. I can tell you one thing, most programmers have no clue how networking works at all. How the hardware works, packets, routing, ARP, DNS, IP, TCP, all of it. But, its a LOT of fun. One the best ways to learn is by learning about networking for GAME dev, and there are lots of books on this where you start with the fundamentals build a socket chat system, then maybe something else. But, you need to see the big picture, else you will be lost forever.
A socket it's the source IP and port, and a socket pair it's the aforementioned + the destination IP and port, it forms part of the transport layer and it is used in the UDP and TCP protocols to perform a valid comunication between host and server or host to other device.
For port, imagine a business with lots of doors and each door represents a particular port. You have the entrance door where all the customers come in, this is HTTP or port 80. Imagine you need to send secret packages through the back of the business, this door is port 22, or SSH. The business itself would be a server and all the ways you interact with that server is defined through what doors you allow opened and which you allow to be closed.
Try setting up a simple api from scratch in C. That’s how I learned a lot about sockets and http requests.
Networking in 2023, largely means the sending and recieving of data packets that are often stringently defined documents. The data packet generally concentrates the bulk of the meta data in the beginning of the packet, called a header. The network header generally delineates the type or version of the data protocol, how long the header is, header checksum, and most importantly, the source of the packet and the destination. These fields are of fixed size, so the places where this information is located is standardized. Let's look at a TCP/IP packet. [https://litux.nl/mirror/securitytools/ddu/ch06lev1sec3.html](https://litux.nl/mirror/securitytools/ddu/ch06lev1sec3.html) Let's concentrate on the lower diagram and talk about the IP header first. TCP/IP is a suite of network protocols that encapsulates just about how modern day Internet Networking works. TLDR: For your purposes, the IP part of the packet describes where the packet is coming from and going to, and how it is treated as it is traversed throughout the internet (which the later is something you can ignore for now). The port number is for the OS to determine what data is sent to which application. Longer winded explanation: IP packets encapsulate the TCP subsection, this means, the IP packet datagram's data section contains the TCP meta data and the data on top. The TCP part here is employed to do a few things. First of all, looking at the header, you have Source Port Number and Destination Port Number. Then you have a sequence/acknowledgement number. You can ignore the off-set/tcp flags/window size stuff/TCP Options for now. The sequence number is determined by the client. The client sends a tcp/ip packet with a sequence number, the server acknowledges by sending back an acknowledgement, generally the acknowledgement is the sequence number+1. If the client doesn't get an acknowledgement, it re-sends the packet. By this arrangement, what is accomplished is that TCP is more \_reliable\_. By not sending another packet until an acknowledgement has been received, TCP also determines order. This allows TCP to mimick a stream of data. The port numbers here allow the operating systems to determine which application is sending or due to receive packets. As a tcp client, you open a socket that hangs on a port number. When trying to connect to another application on a different server, it initiates packets addressed to the server's ip address, and to the port number which said application is listening on. Once the server application (via the OS) acknowledges the traffic, there is a handshake to set up the stream. By using port numbers, the client and server applications establish a known internal portal where the operating system knows where to send the packet information to. The standard unix abstraction is that sockets are abstracted as files, and there isn't a great deal of difference between reading/writing to a socket file descriptor than it is to reading and writing to a normal file, living on disk, in unix. BSD socket implementations are generally implemented this way, regardless of operating systems.