I have few doubts regarding telnet and echo which I haven't got so far lucky with google (also to say I have done my homework)
Does the telnet specification says that there are specific echo port and specific non-echo port?
If yes, Do ports 23 and 10001 differs on that specifically?
If conditional yes, is it some version of telnet protocol specific. In other words were those added after some specific iteration of telnet and/or are their fully compliant telnet clients and partially compliant one (regrading echo)?
also whats the difference if any between localecho and remote echo? I believe I am talking about echo from server side (remote echo?) but in any case which is what?
I am not sure if there is telnet / protocol specific child stackoverflow site? If yes, can somebody point me there?
The IANA Service Name and Transport Protocol Port Number Registry contains all port number registrations and for Telnet it cites RFC 854 as specification which defines
Port Assignment
When used for remote user access to service hosts (i.e., remote
terminal access) this protocol is assigned server port 23
(27 octal). That is L=23.
For the Echo Protocol the RFC number RFC 862 which similarily defines
TCP Based Echo Service
One echo service is defined as a connection based application on TCP.
A server listens for TCP connections on TCP port 7. Once a
connection is established any data received is sent back. This
continues until the calling user terminates the connection.
The port number 10001 is registered for "SCP Configuration".
When a true Telnet server starts, it sends a number of IAC commands to the client telling it how to behave. The server can tell the client to do its own character echo (IAC DO ECHO) or it can tell the client to act dumb (IAC DONT ECHO). The client then confirms its action (IAC WILL ECHO) or inaction (IAC WONT ECHO). If the client responds the opposite of what the server requests then the server can either adapt or continue to insist (and likely eventually fail).
https://www.rfc-editor.org/rfc/rfc857
So to answer your specific question, no, there are not different echo/noecho ports. It's a result of server configuration and client capability. Though technically it is possible to have the telnet server have different configuration on different ports.
You can find a list of special Telnet codes and available do/dont/will/wont options here:
http://www.laynetworks.com/telnet.htm
Related
Let's assume I'm in computer A, I have a few servers running on different ports, but all are basically an instance of the same program (just binding to different ports). Now, computer B, a client, does he need to know what port is the software he wishes to connect to on computer A?
The point is, I am implementing some sort of communication similar to sockets. Everything should work fine but I'm not sure how to create the initial-message from a computer to another - I just don't know to what port to send it to. Does the client know the port he's sending to on the server?
Say here (client): clientsocket.connect(('localhost', 8089)), does the client connect a server running on port 8089? If so, what port is his socket on (what port is he using for the client?
Yes. The only way for the network stack on computer A to know which process to deliver an incoming packet is for computer B to set the correct port in the packet. A web server runs on port 80 by default, but a machine running several distinct web servers will run them on distinct ports, and a client must be specific about which server they want to connect to. http://example.com, http://example.com:8080, and http://example.com:12345 would refer to the servers running on example.com on ports 80, 8080, and 12345, respectively.
In order to know which port to use in your client, you need to read the documentation for the server you want to connect to.
Going in the other direction, the port used by the client to receive responses is typically set by the networking stack automatically. The client doesn't need to do anything special to set it, and the server simply sends packets back to the address/port found in the source portion of the incoming packet.
I need to write my first socket program involving TCP connections. In the program I have created there is a client and server, both of which are the machine I am coding on.However,it requires that I pass the port number as a command line argument. How do I accomplish this?
The answer is simple : Make sure your server and your client agree on the port to use. As long as the port is available and can be used, set up the connected so that the client and server use that same port.
Here's a link that explain the different ranges available for TCP and UDP ports.
As an exemple, the port 3074 is used by microsoft for its Xbox live service. Making an application using this port might interfere with the service.
The port used will be defined either in a configuration file or hard-coded in the source code of both the server and the client. You should easily be able to find it with a quick look at the code or the directory which contains the application.
Usually a web server is listening to any incoming connection through port 80. So, my question is that shouldn't it be that in general concept of socket programming is that port 80 is for listen for incoming connection. But then after the server accepted the connection, it will use another port e.g port 12345 to communicate with the client. But, when I look into the wireshark, the server is always using port 80 during the communication. I am confused here.
So what if https://www.facebook.com:443, it has hundreds of thousands of connection to the it at a second. Is it possible for a single port to handle such a large amount of traffic?
A particular socket is uniquely identified by a 5-tuple (i.e. a list of 5 particular properties.) Those properties are:
Source IP Address
Destination IP Address
Source Port Number
Destination Port Number
Transport Protocol (usually TCP or UDP)
These parameters must be unique for sockets that are open at the same time. Where you're probably getting confused here is what happens on the client side vs. what happens on the server side in TCP. Regardless of the application protocol in question (HTTP, FTP, SMTP, whatever,) TCP behaves the same way.
When you open a socket on the client side, it will select a random high-number port for the new outgoing connection. This is required, otherwise you would be unable to open two separate sockets on the same computer to the same server. Since it's entirely reasonable to want to do that (and it's very common in the case of web servers, such as having stackoverflow.com open in two separate tabs) and the 5-tuple for each socket must be unique, a random high-number port is used as the source port. However, each of those sockets will connect to port 80 at stackoverflow.com's webserver.
On the server side of things, stackoverflow.com can already distinguish between those two different sockets from your client, again, because they already have different client-side port numbers. When it sees an incoming request packet from your browser, it knows which of the sockets it has open with you to respond to because of the different source port number. Similarly, when it wants to send a response packet to you, it can send it to the correct endpoint on your side by setting the destination port number to the client-side port number it got the request from.
The bottom line is that it's unnecessary for each client connection to have a separate port number on the server's side because the server can already uniquely identify each client connection by its client IP address and client-side port number. This is the way TCP (and UDP) sockets work regardless of application-layer protocol.
shouldn't it be that in general concept of socket programming is that port 80 is for listen for incoming connection. But then after the server accepted the connection, it will use another port e.g port 12345 to communicate with the client.
No.
But, when I look into the wireshark, the server is always using port 80 during the communication.
Yes.
I am confused here.
Only because your 'general concept' isn't correct. An accepted socket uses the same local port as the listening socket.
So what if https://www.facebook.com:443, it has hundreds of thousands of connection to the it at a second. Is it possible for a single port to handle such a large amount of traffic?
A port is only a number. It isn't a physical thing. It isn't handling anything. TCP is identifying connections based on the tuple {source IP, source port, target IP, target port}. There's no problem as long as the entire tuple is unique.
Ports are a virtual concept, not a hardware ressource, it's no harder to handle 10 000 connection on 1 port than 1 connection each on 10 000 port (it's probably much faster even)
Not all servers are web servers listening on port 80, nor do all servers maintain lasting connections. Web servers in particular are stateless.
Your suggestion to open a new port for further communication is exactly what happens when using the FTP protocol, but as you have seen this is not necessary.
Ports are not a physical concept, they exist in a standardised form to allow multiple servers to be reachable on the same host without specialised multiplexing software. Such software does still exist, but for entirely different reasons (see: sshttp). What you see as a response from the server on port 80, the server sees as a reply to you on a not-so-random port the OS assigned your connection.
When a server listening socket accepts a TCP request in the first time ,the function such as Socket java.net.ServerSocket.accept() will return a new communication socket whoes port number is the same as the port from java.net.ServerSocket.ServerSocket(int port).
Here are the screen shots.
For example, when you make an ssh connection, you are connected to port 22. What happens then? On a very high level brief overview, I know that if port 22 is open on the other end and if you can authenticate to it as a certain user, then you get a shell on that machine.
But I don't understand how ports tie into this model of services and connections to different services from remote machines? Why is there a need for so many specific ports running specific services? And what exactly happens when you try to connect to a port?
I hope this question isn't too confusing due to my naive understanding. Thanks.
Imagine your server as a house with 65536 doors. If you want to visit family "HTTP", you go to door 80. If you were to visit family "SMTP", you would visit door no. 25.
Technically, a port is just one of multiple possible endpoints for outgoing/incomming connections. Many of the port numbers are assigned to certain services by convention.
Opening/establishing a connection means (when the transport protocol is TCP, which are most of the “classical” services like HTTP, SMTP, etc.) that you are performing a TCP handshake. With UDP (used for things like streaming and VoIP), there's no handshake.
Unless you want to understand the deeper voodoo of IP networks, you could just say, that's about it. Nothing overly special.
TCP-IP ports on your machine are essentially a mechanism to get messages to the right endpoints.
Each of the possible 65536 ports (16 total bits) fall under certain categories as designated by the Internet Assigned Numbers Authority (IANA).
But I don't understand how ports tie into this model of services and
connections to different services from remote machines? Why is there a
need for so many specific ports running specific services?
...
And what exactly happens when you try to connect to a port?
Think of it this way: How many applications on your computer communicate with other machines? Web browser, e-mail client, SSH client, online games, etc. Not to mention all of the stuff running under the hood.
Now think: how many physical ports do you have on your machine? Most desktop machines have one. Occasionally two or three. If a single application had to take complete control over your network interface nothing else would be able to use it! So TCP ports are a way of turning 1 connection into 65536 connections.
For example, when you make an ssh connection, you are connected to
port 22. What happens then?
Think of it like sending a package. Your SSH client in front of you needs to send information to a process running on the other machine. So you supply the destination address in the form of "user#[ip or hostname]" (so that it knows which machine on the network to send it to), and "port 22" (so it gets to the right application running on the machine). Your application then packs up a TCP parcel and stamps a destination and a return address and sends it to the network.
The network finds the destination computer and delivers the package. So now it's at the right machine, but it still needs to get to the right application. What do you think would happen if your SSH packet got delivered to an e-mail client? That's what the port number is for. It effectively tells your computer's local TCP mailman where to make the final delivery. Then the application does whatever it needs to with the data (such as verify authentication) and sends a response packet using your machine's return address. The back and forth continues as long as the connection is active.
Hope that helps. :)
The port is meant to allow applications on TCP/IP to exchange data. Each machine on the internet has one single address which is its IP. The port allows different applications on one machine to send and receive data with multiple servers on the network/internet. Common application like ftp and http servers communicate on default ports like 21 and 80 unless network administrators change those default ports for security reasons
I have 2 sip clients on the same computer.
Both of them is registering to a server that is running on port 5060.
For the first client the UDP is on port 5060 and for the other is 5061. When I come from one client to another, after the ringing part i receive the error:
only one usage of each socket address is normally permited.
Got any ideas why I got this error?
Your server and client are both trying to use port 5060, hence the error message. Change the first client to use 5062 or something else.
Also, 5061 is normally used for secured SIP (normal listening port + 1 in the proxy/server). Do not use it for the second client.
It means you're clients are both trying to claim the same socket for the communication channel, or the server is trying to reclaim the socket given to client A, to reuse it for client B.
The software handeling the socket, should be smart enough to rely on the OS to assign port numbers instead of hardcoding the port numbers in the code, this is a 100% guarantee for socket issues.