On Mon, Apr 9, 2012 at 4:08 PM, Kenny Emond <cheeseylem...@gmail.com> wrote:

>    I'm going to just not beat around the bush. I'll and ask it straight out.
> What the heck are Telnet, TCP and all those other programs that comes with
> mTCP for?

Internet connectivity is done through TCP-IP, a protocol suite.  In
essence, data sent over the internet is broken up into packets.  Each
packet has a header that indicates the source of the packet, the
intended destination, and the total number of packets included in the
particular communication.  TCP-IP was originally developed as part of
research done by DARPA (the Defense Advanced Research Projects Agency)
for a network that could continue to operate even if segments were
damaged.  So there is no inherent route packets will take to a
destination, nor any requirement that all packets take the *same*
route.  It's the responsibility of the routers along the way to
determine best route to use. The idea is that if a node is damaged,
packets can take an alternate route to the destination.  There is also
no requirement that packets arrive in a particular order.  Each packet
carries an indicator of which one it is, and the receiving system is
expected to put packets in the correct order for  whatever will deal
with them before passing them along.

TCP-IP is considered a protocol suite because it includes a number of
different protocols.  All use packets, but the nature and purpose of
the packets will vary.  TCP-IP uses the concept of logical ports to
specify the nature and functions.  There are 65,536 possible ports, of
which the first 1,024 are "well known ports" whose usage has been
standardized.  For instance, an ICMP packet is sent to port 8.  This
is the "ping" - an inquiry as to whether there is a system at the
specified destination awake and answering traffic.  If there is one,
it's expected to acknowledge the ping with a response.  HTTP traffic
is sent to port 80 at the destination, and sending it to that port
indicates it *is* http traffic.

Telnet is used to establish a connection as a terminal to a remote
system.  If the remote system supports it, and you are an authorized
user, you can open a command line session to the remote host and use
whatever the host provides as a shell, as though you were connecting
through a directly attached terminal.   (On a Linux system, this will
usually be the bash shell, but does not have to be.)  For more secure
connections, a popular variant is ssh, which creates an encrypted
communications session with the other end.  By default, telnet uses
port 23 and ssh uses port 22, but these are not requirements: it's
possible to use any port numbers, as long as both sender and receiver
are configured to do so.

I've made use of telnet and ssh as a sysadmin dealing with servers,
using telnet locally (I was connected to the company LAN and local to
the servers) and ssh via remote (as was connecting over the Internet
from home.  There are an assortment of old BBSes from the MS-DOS days
who have made the transition to the Internet, and are accessible via
telnet rather than a dial-up modem connection.

>                     --- A FreeDOS Newser (NEW uSER)

Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
Freedos-user mailing list

Reply via email to