Clients, Servers, and Ports

There are many types of network services, but each service operates in a similar way. For example, let's consider the telnet service. This service allows a user logged in on one UNIX machine (say, machine A) to contact machine B, log on to that machine, and work on the remote machine.

For the connections, TELNET uses the TCP protocol. The TELNET service is offered in the host machine's TCP port 23. The user at the terminal interacts with the local telnet client. The TELNET client acts as a terminal accepting any keystrokes from the keyboard, interpreting them and displaying the output on the screen. The client on the computer makes the TCP connection to the host machine's port 23 where the TELNET server answers. The TELNET server interacts with applications in the host machine and assists in the terminal emulation.

As the connection is setup, both ends of the TELNET connection are assumed to be originated and terminated at the (NVT) network virtual terminal. The NVT is a network wide terminal which is host independent so that both the server and the client in the connection may not need to keep any information about each others terminal's characteristics. Both sides see each other as a NVT terminal. As there are several types of terminals, which may be able to provide additional services from those provided by the NVT, the TELNET protocol contains a negotiation method for the user and the server to negotiate changes to the terminal provided in the NVT. Typically the client and the server stays in the NVT just as long as it takes to negotiate some terminal type to be emulated.

Imagine this: You're ordering a book online (client) from an e-commerce website (server). Clicking "purchase" initiates a **transaction**, a dance between client and server to complete your request. Here's the breakdown:

1. Request: You send a message to the server (think: "I want book X!").
2. Processing: The server receives your request, verifies your details, checks book availability, and calculates costs.
3. Response: The server sends a confirmation message back to you (think: "Got it! Book coming your way.").
4. Data Update: This is where the magic happens! The server updates its database: book inventory decreases, your purchase record is created, payment details are processed (if applicable).
5. Completion: Both client and server receive confirmation – you get an order confirmation email, the server updates its records. Voila, transaction complete!

Key points to remember about WWW transactions:

• Atomicity: The entire transaction succeeds or fails as a whole. No half-bought books!
• Consistency: Data remains consistent throughout the transaction. No phantom books disappearing mid-purchase.
• Isolation: Only your transaction affects the data while it's ongoing. No one else can mess with your book while you're buying it.
• Durability: Once confirmed, the transaction's effects are permanent. Your book order is locked in!

Think of transactions as mini-adventures with servers, ensuring everything goes smoothly from request to confirmation, keeping your online experience safe and reliable.

As a Linux network administrator, you might be familiar with Telnet, which is a network protocol used on the internet or local area networks to provide a bidirectional interactive text-oriented communication facility using a virtual terminal connection. While Telnet is considered insecure for transmitting sensitive data due to its lack of encryption, it's still used in some contexts, particularly in legacy systems or for specific functions where security is not a primary concern. Here are some examples of Telnet services and use cases:

1. Remote Server Management: Telnet can be used for remote management of servers. System administrators can log into servers remotely to manage system settings, install or update software, or troubleshoot issues.
2. Network Equipment Configuration: It's commonly used to configure network hardware like routers, switches, and modems. Manufacturers of these devices often provide a Telnet interface for initial setup or troubleshooting.
3. Testing and Debugging: Telnet can be useful for testing and debugging network services. For example, you can use Telnet to connect to a mail server on port 25 to manually send an email, which can be helpful in diagnosing SMTP issues.
4. Legacy Systems Support: In some legacy systems, Telnet might be the only available method for remote administration, particularly in older industrial, telecommunications, or mainframe systems.
5. Educational Purposes: Telnet is sometimes used in educational settings to teach the basics of network communication and protocols.
6. Telnet "BBS" (Bulletin Board Systems): Historically, Telnet was used to access BBS systems, which were popular before the widespread adoption of the internet. Some of these systems still exist for nostalgia or specific community purposes.
7. MUDs (Multi-User Dungeons): These are multiplayer real-time virtual worlds, usually text-based. Telnet is used to connect to these servers for interactive gameplay.

However, due to security concerns with Telnet (as it sends data, including passwords, in plain text), its use has significantly declined in favor of more secure alternatives like SSH (Secure Shell). SSH provides encrypted communication and is widely considered the standard for secure remote server management and file transfers. As a network administrator, it's generally advisable to use SSH or other secure protocols over Telnet whenever possible, especially for any environment where security is a concern.

INPUT:
telnet www.dispersednet.com 80