WHOIS Protocol - Specifications and characteristics

- WHOIS is a TCP-based transaction-oriented query/response protocol that is widely used to provide information services to Internet users.
- Whois is a draft standard protocol. Its status is elective.
- The protocol delivers its content in a human-readable format.
- WHOIS lacks many of the protocol design attributes, for example internationalization and strong security, that would be expected from any recently-designed IETF protocol.
- The Whois program is commonly used in the UNIX environment to connect to a Whois server. The purpose of the server is to provide directory type services.
- The original Whois server was set up so that the Network Information Center could maintain a contact list for networks connected to the Internet. However, many sites now use Whois to provide local directory services.

The use of the data in the WHOIS system has evolved into a variety of uses, including:
- Supporting the security and stability of the Internet by providing contact points for network operators and administrators.
- Determining the registration status of domain names.
- Assisting law enforcement authorities in investigations for enforcing national and international laws.
- Assisting in the combating against abusive uses of Information communication technology.
- Facilitating inquiries and subsequent steps to conduct trademark clearances and to help counter intellectual property infringement, misuse and theft in accordance with applicable national laws and international treaties.
- Contributing to user confidence in the Internet as a reliable and efficient means of information and communication.
- Assisting businesses, other organizations and users in combating fraud.

Protocol Specification

A WHOIS server listens on TCP port 43 for requests from WHOIS clients. The WHOIS client makes a text request to the WHOIS server, then the WHOIS server replies with text content.

Internationalization

The WHOIS protocol has not been internationalised. The WHOIS protocol has no mechanism for indicating the character set in use.

Network News Transfer Protocol - NNTP

- NNTP specifies a protocol for the distribution, inquiry, retrieval, and posting of news articles using a reliable stream-based transmission of news among the ARPA-Internet community.
- NNTP is designed so that news articles are stored in a central database allowing a subscriber to select only those items he wishes to read. Indexing, cross-referencing, and expiration of aged messages are also provided.
- NNTP is designed so that news articles are stored in a central database allowing a subscriber to select only those items he wishes to read.
- The Network News Transfer Protocol (NNTP) established the technical foundation for the widely used Newsgroups.
- The NNTP protocol is the delivery mechanism for the USENET newsgroup service.
- NNTP is also used by clients who need to read news articles on USENET servers.
- NNTP uses an interactive command and response mechanism that lets hosts determine which articles are to be transmitted.
- Server-to-server exchanges : In the server-to-server exchange, one server either requests the latest articles from another server (pull) or allows the other server to push new articles to it.
- User-to-server connections : The user first connects with a newsgroup server (usually located at an ISP (Internet service provider), then downloads a list of available newsgroups. The user can then subscribe to a newsgroup and begin reading articles available in that group or post new articles.

Protocol Structure - NNTP

NNTP uses commands and responces for communications.
- Article - Display the header, a blank line, then the body (text) of the specified article.
- Head : Identical to the ARTICLE command except that they respectively return only the header lines or text body of the article.
- Status : Similar to the ARTICLE command except that no text is returned.
- Group : The required parameter ggg is the name of the newsgroup to be selected.
- Body : Identical to the ARTICLE command except that they respectively return only the header lines or text body of the article.
- List : Returns a list of valid newsgroups and associated information.
- NewsGroups : A list of newsgroups created since will be listed in the same format as the LIST command.
- ewNews : A list of message-ids of articles posted or received to the specified newsgroup since "date" will be listed.
- Next : The internally maintained "current article pointer" is advanced to the next article in the current newsgroup.
- Post : If posting is allowed, response code 340 is returned to indicate that the article to be posted should be sent.
- Quit : The server process acknowledges the QUIT command and then closes the connection to the client.

POP - Post Office Protocol

Post Office Protocol (POP) is an application-layer Internet standard protocol used by local e-mail clients to retrieve e-mail from a remote server over a TCP/IP connection. The Post Office Protocol (POP) allows you to fetch email that is waiting in a mail server mailbox. POP defines a number of operations for how to access and store email on your server.
It works in conjunction with the SMTP (Simple Mail Transfer Protocol), which provides the message transport services required to move mail from one system to another.

Purpose of POP

If somebody sends you an email it usually cannot be delivered directly to your computer. The message is stored in a place where you can pick it up easily. Your ISP (Internet Service Provider) does this job. It receives the message for you and keeps it until you download it. Now, POP, the Post Office Protocol is what allows you to retrieve mail from your ISP. This is also about all the Post Office Protocol is good for.

What POP allows you to do?

Things that can be done via the POP include:
- Retrieve mail from an ISP and delete it on the server.
- Retrieve mail from an ISP but not delete it on the server.
- Ask whether new mail has arrived but not retrieve it.
- Peek at a few lines of a message to see whether it is worth retrieving.

POP3 is an open Internet standard. The common POP3 commands and responses are :
- getwelcome(): Gets the greeting from the server.
- user(username): Login with a username. If valid username, server will respond with request for password.
- pass_ (password): Send password. If valid, server response will be two numbers, message count and mailbox size.
- stat(): Get the mailbox status. Response is two numbers, message count and mailbox size.
- list([message]): Get list of messages. An option "message" gets information on a specific message.
- retr(message): Get message number "message".
- dele(message): Delete message number "message".
- rset(): Remove all deleted message markings.
- noop(): No operation. Do nothing. Really. Needed in unusual programming situations.
- quit(): Quit. Commits all changes, unlocks the mailbox, and ends the server connection.
- top(message, lines): Gets just the first "lines" number of lines of message number "message". Useful on low bandwidth lines to get just the first part of long messages.
- uidl([message]): Gets a unique id list -- a message digest including unique ids. The option gets the unique id for the specific message "message".

Dynamic Trunking Protocol (DTP)

The Dynamic Trunking Protocol (DTP) is a proprietary networking protocol developed by Cisco Systems for the purpose of negotiating trunking on a link between two VLAN-aware switches, and for negotiating the type of trunking encapsulation to be used. It works on the Layer 2 of the OSI model. If a port can become a trunk, it may also have the ability to trunk automatically, and in some cases even negotiate what type of trunking to use on the port. DTP provides this ability to negotiate the trunking method with the other device.
There are a couple of other potential issues that arise when you start trunking.
- The first issue is that both ends of a trunk cable had better agree they're trunking, or they're going to be interpreting trunk frames as normal frames. To resolve this, Cisco came up with a protocol for switches to communicate intentions. The first version of it was VTP, VLAN Trunking Protocol, which worked with ISL. The newer version works with 802.1q as well, and is called Dynamic Trunking Protocol (DTP).
- The second issue is creating VLAN's.

Switch port modes

- auto : causes the port to passively be willing to convert to trunking. The port will not trunk unless the neighbor is set to on or desirable . This is the default mode.
- on : forces the link into permanent trunking, even if the neighbor doesn't agree.
- off : forces the link to permanently not trunk, even if the neighbor doesn't agree.
- desirable : causes the port to actively attempt to become a trunk, subject to neighbor agreement.
- nonegotiate : forces the port to permanently trunk but not send DTP frames.

Protocol Structure of DTP

On a Catalyst set-based switch, the syntax for setting up a link as a trunk is:

set trunk mod_num/port_num [on | desirable | auto | nonegotiate] [isl | dot1q | negotiate] [vlan_range]
Use this command to set the specified port or ports to trunking.

Some of the challenges involved in the process of using test automation tools

Description of automated decision making problems

In the past decade or so, test automation has jumped up to being a solution touted by a number of experts for improving quality. Even when you consider the case of institutions that provide training on testing concepts, their courses that cost the most are those related to automated testing tools and how to become an expert on using them. However, it should be considered that taking a decision to go for automated testing needs to be a thoroughly considered decision, with the cost and benefits needing to be calculated (in one small company, I realized that the decision to go in for automated testing was made based on the fact that the company had hired 2 people who had done some amount of automated testing earlier). After all, it is very easy to mockup a Excel file and Powerpoint with the benefits of introducing automated testing, but as I said earlier, this should not be a decision taken in haste.

Here are a few points that you should be aware of before you go in for automated testing tools

- Resources: If you are going in for automated testing, then consider the fact that you will need to have more people for your testing team (this also means that some of the people you need will have to have experience with using automated testing). The typical work for a testing team is normally challenging enough, without having to spend the additional time required to automates the test cases.
- Time required: Automation of test cases can take some time to happen. It takes time to learn how to use a testing tool, it takes time to create a proper automation framework, and then starting to write the proper automation scripts and cover all your test cases (or atleast the desired level of test cases that are considered proper for automation).
- Skill set differences. For a team comprising of black box testers, as well as a manager of such people, having a team of people expert in automation testing means a different skill sets. This can cause various morale issues, as well as a lack of understanding of the various specialized needs of the testing team.
- When the application needs to change frequently. During the course of the product development process, the product can change, including the UI. I have seen cases in the past where the UI changes, and the product automation no longer works. In such cases, the script needs to be re-worked, which needs more effort.
- Maintainability of such scripts. Typically, over a period of time, automation scripts need to be maintained, and as people move on in the company, maintaining the same scripts (and ensuring that new people are able to understand the entire structure of the test automation framework) can take increasing periods of effort and time.
- Interlap between test automation areas and manual testing areas. This can be hard to figure for many products where the product functionality cannot be broken down into clean separable areas. In such cases, duplication of testing efforts can happen.
- Expensive. From my experience, the cost needed for test automation is not a one-time effort. We had bought a fairly expensive tool, but then realized that we still had to pay around 40% of the cost annually for the AMC and for the ability to get regular updates.
- Platform compatibility. This was something new that we learnt. We had a product that was only available on Windows, and after a couple of cycles, we also moved onto the Mac and onto Linux because of the potential of getting more sales. And then we realized that our testing tool did not support Linux, and we either needed to get a new tool for Linux (and which meant that we needed to port all our test scripts), or we needed to go in for manual testing (in which case also we did not get the benefits of automated testing on Linux).

CLNP (Connectionless Network Protocol)

CLNP is a datagram network protocol. It provides fundamentally the same underlying service to a transport layer as IP. CLNP provides essentially the same maximum datagram size, and for those circumstances where datagrams may need to traverse a network whose maximum packet size is smaller than the size of the datagram, CLNP provides mechanisms for fragmentation (data unit identification, fragment/total length and offset). Like IP, a checksum computed on the CLNP header provides a verification that the information used in processing the CLNP datagram has been transmitted correctly, and a lifetime control mechanism ("Time to Live") imposes a limit on the amount of time a datagram is allowed to remain in the internet system.

CLNP (Connectionless Network Protocol) may be used between network-entities in end systems or in Network Layer relay systems (or both). CLNP is intended for use in the Subnetwork Independent Convergence Protocol (SNICP) role, which operates to construct the OSI Network Service over a defined set of underlying services, performing functions necessary to support the uniform appearance of the OSI Connectionless-mode Network Service over a homogeneous or heterogeneous set of interconnected subnetworks.

CLNP Protocol Structure

- NLP ID - Network Layer Protocol Identifier : The value of this field is set to binary 1000 0001 to identify this Network Layer protocol as ISO 8473. The value of this field is set to binary 0000 0000 to identify the Inactive Network Layer protocol subset.
- Length ID : Length Indicator is the length in octets of the header.
- Version : Version/Protocol Id Extension identifies the standard Version of ISO 8473.
- Lifetime : PDU Lifetime representing the remaining lifetime of the PDU, in units of 500 milliseconds.
- Flags : There are three flags : segmentation permitted, more segments, error report.
- Type : The Type code field identifies the type of the protocol data unit, which could be data PDU or Error Report PDU.
- Segment Length : The Segment Length field specifies the entire length, in octets, of the Derived PDU, including both header and data (if present).
- Checksum : The checksum is computed on the entire PDU header.

Routing Information Protocol (RIP) Cont...

RIP Message Format

RIP updates are placed as UDP payload inside an IP datagram. The format is as follows:
- Command : It indicates whether the packet is a request or a response. The request asks that a router send all or part of its routing table. The response can be an unsolicited regular routing update or a reply to a request. Responses contain routing table entries. Multiple RIP packets are used to convey information from large routing tables.
- Version number : It specifies the RIP version used. This field can signal different potentially incompatible versions.
- Zero : This field is not actually used by RFC 1058 RIP; it was added solely to provide backward compatibility with prestandard varieties of RIP. Its name comes from its defaulted value: zero.
- Address family identifier (AFI) : It specifies the address family used. RIP is designed to carry routing information for several different protocols. Each entry has an address-family identifier to indicate the type of address being specified. The AFI for IP is 2.
- Address : It specifies the IP address for the entry.
- Metric : It indicates how many internetwork hops (routers) have been traversed in the trip to the destination. This value is between 1 and 15 for a valid route, or 16 for an unreachable route.

RIPv2 header explanation

- Command : Indicates whether the packet is a request or a response.
- Version : Version of RIP.
- Unused : It has a value set to zero.
- Address family identifier (AFI) : It specifies the address family used.
- Route tag : It provides a method for distinguishing between internal routes (learned by RIP) and external routes (learned from other protocols).
- IP address : It specifies the IP address for the entry.
- Subnet mask : It contains the subnet mask for the entry. If this field is zero, no subnet mask has been specified for the entry.
- Next hop : It indicates the IP address of the next hop to which packets for the entry should be forwarded.
- Metric : It indicates how many internetwork hops (routers) have been traversed in the trip to the destination. This value is between 1 and 15 for a valid route, or 16 for an unreachable route.