COMPUTERS AND MORE

SOCKET PROGRAMMING

Sockets are interfaces that can "plug into" each other over a network. Once so "plugged in", the programs so connected communicate.

This article discusses only simple aspects of stream inet sockets (don't worry about exactly what that is right now). For the purposes of this article, a "server" program is exposed via a socket connected to a certain /etc/services port number. A "client" program can then connect its own socket to the server's socket, at which time the client program's writes to the socket are read as stdin to the server program, and stdout from the server program are read from the client's socket reads. This is one subset of socket programming, but it's perhaps the easiest to master, so this is where you should start.

This tutorial requires a Linux box. It hasn't been tested on other types of UNIX, but I think it might work. This tutorial is centered around a system using xinetd, but it would be simple enough to adapt it to older inetd systems. This tutorial will not work under Windows. I think it's important that this complex type of programming be learned on the most reliable, straightforward system possible, so Windows is out.

For the purposes of this tutorial, the server application will be at port 3333. Note that you can implement both the client and the server on a single computer, in which case the client is connected to a port on the computer containing both the client and the server. So if you have only one Linux box you can still do this tutorial.

Acknowledgments

This material was told to me by LEAP-CF members Mark Alexander and Nickolai Zeldovich. Other LEAPsters provided additional information.

A big shout out to all my buddies at Linux Enthusiasts and Professionals of Central Florida (LEAP-CF). With mailing list and meetings, they (we) form a 70 brain parallel supercomputer.

And of course, thanks to the help and support of Troubleshooters.Com's visitors.

Hello World

Our first socket implementation uses a simple write-only shellscript as a server application, and telnet as the client. This is the simplest possible implementation. I've tested this on a mandrake box, and I'd imagine it would work on any Linux box using xinetd. If your box still uses the older inetd system, the only difference is that you modify inetd.conf instead of a file in /etc/xinetd.d, and you restart inetd instead of xinetd. The following steps are involved:

1. Create the server application (a simple shellscript)
2. Test the server application at the command line
3. Decide on a port number and service name
4. Declare the port and name in /etc/services
5. Create a file for this service in /etc/xinetd.d
6. Restart xinetd
7. Telnet into the service, and see the server app's output
8. Review what you learned

Create the server application (a simple shellscript)

We want the simplest possible script for this Hello World, so here it is:

Save the preceding script as hello.sh, in your home directory (we'll assume your user id is myuid).

Note several things. The top line, showing the program to read the script, is ABSOLUTELY ESSENTIAL. Although most environments run shellscripts without that top line, those same scripts will not output when called through sockets as certain users (user nobody, for instance). For a similar reason, make sure every executable is declared with a complete path, and is not a link. With a user like user nobody, you don't know what the path will look like. Similarly, the log file is completely specified so you know where to find it. If you don't specifiy it, it goes in the home directory of the user hooked to the service by xinetd. Better to specify it so you know exactly where to find it. /tmp is an excellent place, because on most systems it has universal read and write permissions.

This script writes a single line containing "Hello World:" followed by a timestamp, both to stdout and to a log file called /tmp/log.log. The log file will become essential in socket debugging, because when the program runs under a socket the program has no terminal.

For security reasons, I recommend you implement the client and server on the same computer, and that you temporarily disconnect that computer from your network. The last thing you want is an under-development service exposed to your LAN, and maybe the entire Internet.

Be sure to set the script as executable by all. Remember, you don't know what user will be executing it. Also, be sure the entire directory tree housing the script is executable by all, or else other users won't be able to traverse the tree to execute the file.

Test the server application at the command line

Run the program, and it should output the hello world phrase followed by a timestamp. When you look at /tmp/log.log it should contain the same information. See the session below:

If you don't get the results shown above, troubleshoot until you do.

Decide on a port number and service name

First, the port number needs to be unused. The port number you choose should not exist in /etc/services. Furthermore, for security reasons the port number should not be below 1024. For this exercise I use port 3333. You may wish to use a different port so someone knowing you've taken this tutorial doesn't know of an open port on your system. But in this tutorial I'll use 3333.

The first thing to do is make sure the port number is not contained in the /etc/services file. Do that as follows:

If there's no output, there's no such port number. If there's output, investigate thoroughly, and you'll probably want to select a different number.

You also need to check for the existence of an xinetd declared service with a declared port number matching the new one. Do that with a directory wide grep:

Once again, no output means no such port is declared. If there is output, investigate, and change your new port number if necessary.

As far as the service name, we're going to call the service "hello". Here's how we check for the existence of a current service called "hello":

Once again, if there's no output, there's no such service yet, so you're free to use that service name.

Once you've decided on a port number and a service name (3333 and hello in this tutorial), continue on...

Declare the port and name in /etc/services

Add the following line to the /etc/services file:

The first field is the service name. The second field is the port number and the type of protocol (tcp in this case). Anything to the left of a hash mark (#) is a comment.

Beware: The xinetd man page says an xinetd invoked service needn't be declared in /etc/services. That does not match my experience. I was unable to make this work without declaring it in /etc/services, even using the xinetd port= parameter. Make your life easy. Declare it in /etc/services for the purposes of this tutorial. Then, if you wish, go ahead and find a way to remove it from /etc/services while retaining the service.

Create a file for this service in /etc/xinetd.d

As user root, create the following file in /etc/xinetd.d:

As root, save the preceding file as /etc/xinetd.d/hello. It should read/write for owner, read for group and other:

Once you've saved the file properly, you're ready to "turn on" the server by restarting xinetd...

Restart xinetd

According to the xinetd man page there are many ways to "reconfigure" xinetd. In the xinetd man page search for SIGUSR2 and you'll find some of the less intrusive methods. But in my experience, there's no substitute for a known state. I prefer a complete restart. Here's how it's done on a Mandrake box:

Different Linux distros use different commands and output different text. So your mileage may vary. Once you've restarted xinetd, your new service is theoretically working. Time to test using telnet as a client...

Telnet into the service, and see the server app's output

Run the following command:

telnet 192.168.100.2 3333

The IP address is the address of the server containing the hello world server. The 3333 is the port number. Here's one example of what might happen:

In the preceding, note the "Connection refused" message. This means there's a basic problem with the service, and the user listed in /etc/xinetd.d/hello cannot run hello.sh. Note that the log file will not have been rewritten, so if one exists it has an old timestamp (this is why we put the timestamp in the server script). Here are some things to check:

• Make sure the service and name are listed in /etc/services.
• In /etc/xinetd.d/hello, make sure:
• The port= line's value matches the port number in /etc/services.
• The service name (just before the squiggly braces) is correct.
• If there's a disable=, its value must be no.
• If there's a default: line, its value must be on.
• The user= line names a valid user.
• The server= line must point to the script to be run (hello.sh). It must be fully pathed.

After correcting any problems, restart xinetd:

/etc/rc.d/init.d/xinetd restart

If none of the above helps, try TEMPORARILY changing the user= line to root. That should fix any permission problems. But make sure that before you change it to root, you disconnect from the Internet. Otherwise the script kiddies will be on you like squirrels on a tree.

If none of the above helps, use the Universal Troubleshooting Process to diagnose the problem. Try to find ways to narrow the problems, and ways to divide and conquer.

Once you actually get the connection to work, you may be confronted with a no-output run, as shown below:

In the preceding, the connection was made, but no output was recieved. There's probably something wrong with the script itself. Most likely the top line declaring the script's interpreter (/bin/bash in this example) is missing or wrong. It could also be a pathing problem with the "run service as" user, which is why it's so important to fully path all files in the script. Note that the log file will not have been rewritten, so if one exists it has an old timestamp (this is why we put the timestamp in the server script).

Verify that the script's name is the same as named in /etc/xinetd.d/hello, that it's executable for all, that its directory is executable all the way up the path, and that it contains the #!/bin/bash line at the top, and that there really is a /bin/bash, and that it's a command interpreter. Verify that all files in the script are fully pathed. Beyond that, troubleshoot.

Once you get it running, you might get output like the following:

You can tell you're close. You're connecting, and you're getting output obviously originating from your script. But you have a problem creating /tmp/log.log. That's not surprising, because in a previous step you created it as user myuid, and user nobody hasn't the permissions to delete the old one. As root or another user permissioned to delete /tmp/log.log, delete the old one manually and you should clear the problem. Once all problems have been cleared, the telnet session should look as follows:

If you obtain the preceding output, congratulations -- you've just implemented a Hello World sockets setup. So let's review...

Review What You've Learned

Sockets are a software methodology to connect different processes (programs) on the same computer or on different computers. The name "socket" reminds us that once we "plug in" one process into another process's socket, they can talk to each other by reading and writing the socket.

Sockets are a huge and diverse subject. This tutorial deals with the subset in which one of the two processes is a "server" by virtue of its configuration into xinetd (or inetd if you're running an older UNIX or Linux distro). In such a scenario, the "server" process, which in our example is a simple shellscript, is associated with a port number and a process name via a config file in the /etc/xinetd.d directory. In our case, the file is /etc/xinetd.d/hello. Additionally, the port number is associated with the service name and the tcp protocol via an entry in /etc/services. Once those associations are made, restarting xinetd makes the script available as a service at the specified port. Pictorially, it looks something like this:

In the case of our tutorial, we used telnet as the client program, connecting it to port 3333 on 192.168.100.2 as follows:

telnet 192.168.100.2 3333

The server script's output then appears in the telnet program's output.

This has been a simple implementation indeed. You didn't code the client, but instead used telnet. And communication goes only one way. It's output from the server app and read in telnet. Nevertheless, you're over the biggest hurdle.The next step is two way socket communication. Read on...

A Bidirectional Implementation with Telnet Client

Now let's make a bidirectional program. We'll simply attach a new script, called hellobidirectional.sh, to the hello service. First, let's make the hellobidirectional.sh script:

Warning: The ^M is a CTRL+M, a single character. Unfortunately, this html page can represent it only as a carat followed by an M. If you copy and paste this script into VI, be sure to change the carat and M to a genuine CTRL+M! If your script works on the command line but appears to garble the first name in Telnet, be sure to check for a legitimate CTRL+M.

This script repeatedly queries for a first name, and for three Linux celebrities it returns their last name. For other people it returns the string "Unknown celeb", and for any first name beginning with q it terminates, as you can see in the case statement.

Make the script executable by all, and once again make sure its diirectory is executable all the way up the tree. Now run it from the command line. The results should look something like the following, keeping in mind that the bolded text is what you typed in:

Now you know you have a working script. The next step is to attach this script to the hello service. Simply edit /etc/xinetd.d/hello, and replace the following line:

server = /home/slitt/hello.sh

With the following line:

server = /home/slitt/hellobidirectional.sh

Now restart xinetd with the following command:

/etc/rc.d/init.d/xinetd restart

And finally, use telnet as the client. The following shows the telnet session with text you type bolded:

If the first names returned by the script (the first names after the ones you type in) are garbled, suspect that the sed command is not removing telnet's trailing CTRL+M characters, and investigate. Troubleshoot any problems as necessary.

A Bidirectional Implementation with Custom C Client

Use the exact same hellobidirectional.sh you used in the A Bidirectional Implementation with Telnet Client section. But this time we'll access it with a C client. It's not as simple as it might seem. If this section does its job right, you'll learn some of the socket comm gotchas, how to recognize them, how to overcome them, and why professional strength socket clients and servers must know about each others' protocols.

File Blocking, and Deadly Embraces

One problem you'll see in your career as a socket programmer is file blocking. If you attempt to read an empty socket, you'll wait until the server sends more data. Forever if necessary. That's called File Blocking, and it's the default behavior of sockets. Let's say your client code has a "read all data sent" function containing code something like this:

while((len = read(sd, buf, buflen)) > 0)

write(1,buf,len);

That's standard Programming 101, and works perfectly with normal files. But with sockets, the default behavior (called blocking) is that when the read that would have returned 0 is attempted, the read waits for data to come in. So what's wrong with that?

The client is waiting for data from the server, and will not send data to the server until it receives data from the server. But the server will send no data to the client until it receives data from the client. Deadly embrace! The preceding code snippet will hang a socket client under normal conditions. Blocking can be removed with ioctl(), or the buffer can be peeked into with select() or poll(). But these are all rather complicated.

As a Hello World compatible solution (kludge really), instead of reading past the end of data, we'll read up to the end of data by terminating the loop when we read less than the requested number of bytes:

while((len = read(sd, buf, buflen)) >= buflen)

write(1,buf,len);

Interestingly enough, even though you requested to read past the end of data, it returns only up to the end of data. Blocking doesn't occur until you try to read a completely drained socket. There's a bug in the preceding code. If the data in the socket is an exact multiple of buflen, the loop won't terminate on end of data, but will try one more read on an empty buffer, causing the previously described deadly embrace. Although in production code that would be inexcusable, in this Hello World exercise we simply minimize the likelihood of it happening by making the buffer large with respect to the expected data. 512 is a good number, and that's what we will use in the client.

Timing Issues -- the sleep() Solution

Imagine this. After the user inputs data into the client, the client sends data to the server, then quickly iterates the loop and grabs server data out of the socket. The only trouble is, the server hasn't sent the data yet because it hasn't received data from the client. So the client says "the server gave me no data" and proceeds to the next requst for user input. Some time during that user input the server recieves the previous client iteration's data, and sends back a response. This is how server responses can continously be one iteration behind the client, making for user confusion and a Troubleshooter migraine.

Because this exercise is only to teach theory, we "solve" this problem with an expedient kludge -- we insert a sleep() command immediately after the client writes data to the socket. In that way, we guarantee that the server gets the client data and returns its response before the client tries to grab the response. For a similar reason, a sleep() is inserted immediately after the client connects to the socket. For a socket connection to a server on the same box, a 1 second sleep is sufficient. On a heavily trafficked network, that interval may need to be increased.

Please remember, the purpose of this kludge is so you can learn socket programming fundimentals without needing to learn about protocols, stop characters, blocking, ioctl(), and a host of other stuff. As time goes on I will add content to this page describing and walking you through the right way to accomplish these things.

The Client Code

So here, without further adieu, is the client code:

The main routine can be divided roughly into two parts:

1. Socket initialization with connection, ending with its connect statement and associated error handling
2. Interaction with server via socket, beginning with the first sleep() command.

Believe it or not, part 1 is the more straightforward. Basically, you prepare a socket descriptor (sd) by creating it, initializing a hostent struct (host) and a sockaddr_in struct (sin). Various copies and other calls prepare the socket descriptor, and then the connect statement connects the socket descriptor with the service defined in the sockaddr_in struct. Once that connect is done, the socket descriptor can be treated very much like a file descriptor or file handle. They're both integers, and they can both be used in read() and write() calls.

The second part is the challenge. Most obvious, there's no clean way to end the loop unless we get a clue from the server. In this case, the server prints the word "Finished" when it's finished. We create a function called printFromSocket() to handle all aspects of reading server data from the socket, as well as telling the main loop when "Finished" has been recieved so we can terminate the loop.

To prevent deadly embrace, the printFromSocket() function does the "to the end but not beyond" read discussed previously. It also searches for the word "Finished" after every read. When it finds that string it terminates its loop and also returns the fact that it found that string, so that the main loop can terminate. An understanding of the printFromSocket() function yields a good understanding of this client program.

Other than the above, the only tricky part is that a sleep() is inserted after the connect, and after every data transmission from the client. This is to prevent the timing problems previously discussed.

Conclusion

Although the preceding exercises were obviously academic, using workarounds unacceptable in production code, upon their completion you have an excellent understanding of socket basics. At this point you can take advantage of more advanced socket documentation to learn to make production code. And better still, in the coming months I'll be adding more info to this page...

Looking Ahead

I'll be placing some more content on this page in the coming months. That content will address the practicalities of production code, eliminating the need for the obvious kludges you've seen in the previous exercises. Some of the issues that will be addressed are:

• Turning off blocking with ioctl()
• Buffer introspection with select() and poll()
• Using end of transmission and end of program bytecodes to implement synchronous timing the right way, instead of the sleep() workaround.
• Discussing differences between synchronous and asynchronous communication between client and server. Asynchronous communication occurs when the client can respond to the server's data at any time, regardless of the client's state. And vice versa -- the server can respond to the client's data at any time, regardless of the server's state. Telnet is an excellent example of asynchronous client-server communication.
• Creating a Perl server app
• Creating a Perl client

A Perl Socket Server

Within an isolated network, you can assign IP addresses at random as long as each one is unique. However, connecting a private network to the Internet requires using registered IP addresses (called Internet addresses) to avoid duplicates.

The four numbers in an IP address are used in different ways to identify a particular network and a host on that network. Four regional Internet registries -- ARIN, RIPE NCC, LACNIC and APNIC -- assign Internet addresses from the following three classes.

· Class A - supports 16 million hosts on each of 126 networks

· Class B - supports 65,000 hosts on each of 16,000 networks

· Class C - supports 254 hosts on each of 2 million networks

The number of unassigned Internet addresses is running out, so a new classless scheme called CIDR is gradually replacing the system based on classes A, B, and C and is tied to adoption of IPv6.

An IP address (Internet Protocol address) is a unique address that certain electronic devices use in order to identify and communicate with each other on a computer network utilizing the Internet Protocol standard (IP)—in simpler terms, a computer address. Any participating network device—including routers, switches, computers, infrastructure servers (e.g., NTP, DNS, DHCP, SNMP, etc.), printers, Internet fax machines, and some telephones—can have its own address that is unique within the scope of the specific network. Some IP addresses are intended to be unique within the scope of the global Internet, while others need to be unique only within the scope of an enterprise.

The IP address acts as a locator for one IP device to find another and interact with it. It is not intended, however, to act as an identifier that always uniquely identifies a particular device. In current practice, an IP address is not always a unique identifier, due to technologies such as dynamic assignment and network address translation.

IP addresses are managed and created by the Internet Assigned Numbers Authority (IANA). The IANA generally allocates super-blocks to Regional Internet Registries, who in turn allocate smaller blocks to Internet service providers and enterprises.

IP versions

The Internet Protocol (IP) has two versions currently in use (see IP version history for details). Each version has its own definition of an IP address. Because of its prevalence, "IP address" typically refers to those defined by IPv4.

An illustration of an IP address (version 4), in both dot-decimal notation and binary.

IP version 4 addresses

Main article: IPv4#Addressing

IPv4 only uses 32-bit (4-byte) addresses, which limits the address space to 4,294,967,296 (2³²) possible unique addresses. However, many are reserved for special purposes, such as private networks (~18 million addresses) or multicast addresses (~270 million addresses). This reduces the number of addresses that can be allocated as public Internet addresses, and as the number of addresses available is consumed, an IPv4 address shortage appears to be inevitable in the long run. This limitation has helped stimulate the push towards IPv6, which is currently in the early stages of deployment and is currently the only contender to replace IPv4.

IPv4 addresses are usually represented in dotted-decimal notation (four numbers, each ranging from 0 to 255, separated by dots, e.g. 147.132.42.18). Each range from 0 to 255 can be represented by 8 bits, and is therefore called an octet. It is possible, although less common, to write IPv4 addresses in binary or hexadecimal. When converting, each octet is treated as a separate number. (So 255.255.0.0 in dot-decimal would be FF.FF.00.00 in hexadecimal.)

IPv4 address networks

Main article: Subnetwork

Currently, three classes of networks are commonly used. These classes may be segregated by the number of octets used to identify a single network, and also by the range of numbers used by the first octet.

• Class A networks (the largest) are identified by the first octet, which ranges from 1 to 126.
• Class B networks are identified by the first two octets, the first of which ranges from 128 to 191.
• Class C networks (the smallest) are identified by the first three octets, the first of which ranges from 192 to 223.

Some first-octet values have special meanings:

• First octet 127 represents the local computer, regardless of what network it is really in. This is useful when testing internal operations.
• First octet 224 and above are reserved for special purposes such as multicasting.

Octets 0 and 255 are not acceptable values in some situations, but 0 can be used as the second and/or third octet (e.g. 10.2.0.100).

A class A network does not necessarily consist of 16 million machines on a single network, which would excessively burden most network technologies and their administrators. Instead, a large company is assigned a class A network, and segregates it further into smaller sub-nets using Classless Inter-Domain Routing. However, the class labels are still commonly used as broad descriptors.

IPv4 private addresses

Main article: Private network

Machines not connected to the outside world (e.g. factory machines that communicate with each other via TCP/IP) need not have globally-unique IP addresses. Three ranges of IPv4 addresses for private networks, one per class, were standardized by RFC 1918; these addresses will not be routed, and thus need not be coordinated with any IP address registrars.

Each block is not necessarily one single network, although it is possible. Typically the network administrator will divide a block into subnets; for example, many home routers automatically use a default address range of 192.168.0.0 - 192.168.0.255 (192.168.0.0/24).

An illustration of an IP address (version 6), in hexadecimal and binary.

IP version 6 addresses

Main article: IPv6#Addressing

IPv6 is a new standard protocol intended to replace IPv4 for the Internet. Addresses are 128 bits (16 bytes) wide, which, even with a generous assignment of netblocks, will more than suffice for the foreseeable future. In theory, there would be exactly 2¹²⁸, or about 3.403 × 10³⁸ unique host interface addresses. Further, this large address space will be sparsely populated, which makes it possible to again encode more routing information into the addresses themselves.

Example: 2001:0db8:85a3:08d3:1319:8a2e:0370:7334

Writing for Technology Review in 2004, Simson Garfinkel wrote notes that there will exist "roughly 5,000 addresses for every square micrometer of the Earth's surface".^[1] This enormous magnitude of available IP addresses will be sufficiently large for the indefinite future, even though mobile phones, cars and all types of personal devices are coming to rely on the Internet for everyday purposes.

The above source, however, involves a common misperception about the IPv6 architecture. Its large address space is not intended to provide unique addresses for every possible point. Rather, the addressing architecture is such that it allows large blocks to be assigned for specific purposes and, where appropriate, aggregated for providing routing. With a large address space, there is not the need to have complex address conservation methods as used in classless inter-domain routing (CIDR).

Windows Vista, Apple Computer's Mac OS X, and an increasing range of Linux distributions include native support for the protocol, but it is not yet widely deployed elsewhere.

IP v 6 private addresses

Just as there are addresses for private, or internal networks in IPv4 (one example being the 192.168.0.0 - 192.168.255.255 range), there are blocks of addresses set aside in IPv6 for private addresses. Addresses starting with FE80: are called link-local addresses and are routable only on your local link area. This means that if several hosts connect to each other through a hub or switch then they would communicate through their link-local IPv6 address.

Early designs specified an address range used for "private" addressing, with prefix FEC0. These are called site-local addresses (SLA) and are routable within a particular site, analogously to IPv4 private addresses. Site-local addresses, however, have been deprecated by the IETF, since they create the same problem that does the existing IPv4 private address space (RFC 1918). With that private address space, when two sites need to communicate, they may have duplicate addresses that "combine". In the IPv6 architecture, the preferred method is to have unique addresses, in a range not routable on the Internet, issued to organizations (e.g., enterprises).

The preferred alternative to site-local addresses are centrally assigned unique local unicast addresses (ULA). In current proposals, they will start with the prefix FC00.

Neither ULO nor SLA nor link-local address ranges are routable over the internet.

IP address subnetting

Main article: Subnetwork

Both IPv4 and IPv6 addresses utilize subnetting, or dividing the IP address into two parts: the network address and the host address. By using a subnet mask, the computer can determine where to split the IP address.

Static and dynamic IP addresses

When a computer uses the same IP address every time it connects to the network, it is known as a Static IP address. In contrast, in situations when the computer's IP address changes frequently (such as when a user logs on to a network through dialup or through shared residential cable) it is called a Dynamic IP address

Method of assignment

Static IP addresses are manually assigned to a computer by an administrator. The exact procedure varies according to platform. This contrasts with dynamic IP addresses, which is assigned either randomly (by the computer itself, as in Zeroconf), or arbitrarily assigned by a server using Dynamic Host Configuration Protocol (DHCP). Even though IP addresses assigned using DHCP may stay the same for long periods of time, they can generally change. In some cases, a network administrator may implement dynamically assigned static IP addresses. In this case, a DHCP server is used, but it is specifically configured to always assign the same IP address to a particular computer, and never to assign that IP address to another computer. This allows static IP addresses to be configured in one place, without having to specifically configure each computer on the network in a different way.

In the absence of both an administrator (to assign a static IP address) and a DHCP server, the operating system may still assign itself a dynamic IP address using Zeroconf. These IP addresses are known as link-local addresses. For IPv4, link-local addresses are in the 169.254.0.0/16 address range.

Uses of dynamic addressing

Dynamic IP Addresses are most frequently assigned on LANs and broadband networks by Dynamic Host Configuration Protocol (DHCP) servers. They are used because it avoids the administrative burden of assigning specific static addresses to each device on a network. It also allows many devices to share limited address space on a network if only some of them will be online at a particular time. In most current desktop operating systems, dynamic IP configuration is enabled by default so that a user does not need to manually enter any settings to connect to a network with a DHCP server. DHCP is not the only technology used to assigning dynamic IP addresses. Dialup and some broadband networks use dynamic address features of the Point-to-Point Protocol.

Uses of static addressing

Static addressing is essential in some infrastructure situations, such as finding the Domain Name Service directory host that will translate domain names to numbers (IP addresses). Static addresses are also convenient, but not absolutely necessary, to locate servers inside an enterprise. An address obtained from a DNS server comes with a time to live, or caching time, after which it should be looked up to confirm that it has not changed. Even static IP addresses do change as a result of network administration, however (RFC 2072).

Modifications to IP addressing

IP blocking and firewalls

Main articles: IP blocking and Firewall

Firewalls are common on today's Internet. For increased network security, they allow or deny access to their private network based on the public IP of the client. Whether using a blacklist or a whitelist, the IP address that is blocked is the perceived public IP address of the client, meaning that if the client is using a proxy server or NAT, blocking one IP address might block many individual people.

IP address translation

Main article: Network Address Translation

IP addresses can appear to be shared by multiple client devices either because they are part of a shared hosting web server environment or because an IPv4 network address translator (NAT) or proxy server acts as an intermediary agent on behalf of its customers, in which case the real originating IP addresses might be hidden from the server receiving a request. A common practice is to have a NAT hide a large number of IP addresses in a private network. Only the "outside" interface(s) of the NAT need to have Internet-routable addresses^[2].

Most commonly, the NAT device maps TCP or UDP port numbers on the outside to individual private addresses on the inside. Just as there may be site-specific extensions on a telephone number, the port numbers are site-specific extensions to an IP address.

In small home networks, NAT functions are usually performed by a residential gateway device, typically one marketed as a "router". In this scenario, the computers connected to the router would have 'private' IP addresses and the router would have a 'public' address to communicate with the Internet. This type of router allows several computers to share one public IP address.

Bluetooth is a specification for the use of low power radio communications to wireless phones,computers, and other network wireless devices over short distances. The name Bluetooth is actually borrowed from Harald Bluetooth, a Denmark king more than 1,000 years ago.

The technology of Bluetooth was primarily designed to support simple wireless networking of devices and peripherals, which includes cell phones, PDAs,and wireless headsets. The wireless signals that are transmitted by Bluetooth cover short distances of up to 30 feet, generally communicating less than 1 MPps (Mega Byte per second).

The networks of Bluetooth feature dynamic topology called PAN or a piconet. The piconets contain aminumum of two and a maximum of eight peer devices. The devices will communicate using protocols that are part of the specification.

Even though the Bluetooth standard will utilize the same 2.4 GHz range as 802.11b and 802.11g, the technology isn't suitable for a Wi-Fi replacement. When compared to Wi-Fi, Bluetooth is much slower, limited in range, and actually supports less devices.

For short range devices, Bluetooth is rapidly becoming the best. The technology is more popular with cell phones, as Bluetooth headsets are the way to go these days. To use Bluetooth, your cell phone will need to have it enabled, or an infared device somewhere on the phone.

Upcoming devices are utilizing Bluetooth as well, such as PS3 and the Nintendo Revolution. The wireless controllers will be Bluetooth enabled,which will give players the cutting edge.

If you own a cell phone or other wireless device, you should look into Bluetooth. The technologyis nothing short of spectacular, making it something that will be around for years and years to come. As technology gets bigger and bigger, you can expect Bluetooth to advance as well.

Many people don't like cables. When people want to copy information from their old mobile phone to their new mobile phone many makes and models including Nokia, LG and Samsung allow the user to "blue tooth accross" their text messages, phone book enteries and sometimes phone settings.

Nokia bluetooth mobile handsets are particually good at this. When a person orders a mp3 ringtone or real tone, they can send it to thier friend for free over bluetooth instead of sending it as a text message through their mobile network which they may get changed for.

Certain mobile phone based chat clients can use blue tooth to communicate, with the benefit again of the mobile phone opeartors billing being totally cut out.

Many video streaming mobile phones are equipped with bluetooth. Even though having bluetooth switched on does cause a significant battery drian, bluetooth is a far better technology for power consumption over the other options including WiFi.

Happy 10 Year Anniversary for Bluetooth Technology!

Bluetooth Security

Bluetooth Security

· The Bluetooth SIG Focuses on Security

The Bluetooth SIG is constantly improving formats for combating security threats associated with Bluetooth technology. Offering a secure method to wirelessly communicate has always been one of the key benefits of Bluetooth technology. If you look at The History of Bluetooth, you will see that offering secure data transmission was one of the core principles for its creation.

In order to lead the security effort, a group of engineers within the Bluetooth SIG formed the Bluetooth Security Experts Group. As the Bluetooth Core Specification Versions continue to advance, the Bluetooth Security Experts Group is responsible for monitoring the advancement and testing for flaws in its security.

· The Fundamentals of Bluetooth Security

One of the most basic levels of security for Bluetooth devices is the “pairing” process.

Pairing = Two or more Bluetooth devices recognize each other by the Bluetooth Profiles they share, and in most cases, both must enter the same PIN.

The Bluetooth core specifications use an encryption algorithm, which is entirely secure. Once Bluetooth devices pair with one another, they too are entirely secure.

Bluetooth devices will not communicate with each other until they have successfully paired. So, because of this pairing process and the fact that it has a short range, Bluetooth technology is considered to be fundamentally secure.

Unfortunately, as recent news has indicated, experienced hackers have come up with a way to get around this basic level of security. However, there are precautions users can take to limit the chances of their Bluetooth device from being compromised by a hacker.

· How Developers Can Provide Security

Companies who develop Bluetooth enabled products have multiple options in order to provide security. There are three security modes for connecting two Bluetooth devices:

1. Security Mode 1: non-secure
2. Security Mode 2: service level enforced security
3. Security Mode 3: link level enforced security

It is the company who develops each specific Bluetooth product that decides which security modes to use. Also, the devices and services have different security levels as well. For example, devices use two levels: "trusted device" and "untrusted device". After a trusted device is connected to another device, it has unrestricted access to all services. As far as services, there are three security levels which are defined: services that require authorization and authentication, services that require authentication only and services that are open to all devices.

· Why Have There Been Security Threats?

The recent Bluetooth security threats have been isolated to Bluetooth cell phones. The issues were due to specific problems with the cell phone’s platforms. In order to solve, and prevent against further security probelems, the Bluetooth SIG and all of its members work together to discover, inspect and solve reported problems.

If there is something wrong with the actual Bluetooth specification, then the Bluetooth SIG will confront the problem directly. However, if the problem is a result of the implementation of Bluetooth technology, then the SIG will work with the specific members in order to release patches and prevent future problems from occurring.

· What is Bluejacking?

Bluejacking allows phone users to send business cards anonymously to one another using Bluetooth technology. Bluejacking does NOT involve any altercations to your phone's data. These business cards usually consist of some clever message or joke. Bluejackers are simply looking for a reaction from the recipient. To ignore bluejackers, simply reject the business card, or if you want to avoid them entirely, set your phone to non-discoverable mode

· What is Bluesnarfing?

Bluesnarfing refers to a hacker who has gained access to data, which is stored on a Bluetooth enabled phone. Bluesnarfing allows the hacker to make phone calls, send and receive text messages, read and write phonebook contacts, eavesdrop on phone conversations, and connect to the Internet. The good news is, bluesnarfing requires advanced equipment and expertise or requires the hacker to be within a 30 ft. range. If your phone is in non-discoverable mode, it becomes significantly more difficult for hackers to bluesnarf your phone. According to the Bluetooth SIG, only some older Bluetooth enabled phones are vunerable to bluesnarfing.

· What is Bluebugging?

Bluebugging refers to a skilled hacker who has accessed a cell phone's commands using Bluetooth technology without the owner's permission or knowledge. Bluebugging allows the hacker to make phone calls, send messages, read and write contacts and calendar events, eavesdrop on phone conversations, and connect to the Internet. Just like all Bluetooth attacks, the hacker must be within a 30 ft. range. Bluebugging and bluesnarfing are separate security issues, and phones that are vulnerable to one are not necessarily vulnerable to the other.

· What are Phone Manufacturers Doing to Solve These Problems?

Two of the leading cell phone manufacturers, Nokia and Sony Ericsson, have developed software patches for phones susceptible to bluesnarfing and bluebugging. Also, both manufacturers have taken great measures to ensure new phones entering the market will not be susceptible to these attacks.

· Are There Any Other Threats With Bluetooth Technology?

According to the Bluetooth SIG, bluesnarfing and bluebugging are the only known security threats. The Bluetooth SIG is constantly researching security risks associated with the technology and figure out if the risk is even possible as the technology expands and develops.

· What Can Users Do to Protect Their Data?

There are several measures users can take in order to protect their device’s information:

1. If a phone is vulnerable to bluesnarfing or bluebugging--contact the manufacturer or take the phone to a manufacturer-authorized dealer. There are software patches available for many older Bluetooth phones.
2. Turn the device to non-discoverable mode when not using Bluetooth technology.
3. Never pair with unknown devices or in public places.
4. When possible, use an eight character or more alphanumeric PIN.

Specifications about Bluetooth

Bluetooth Specifications

Bluetooth Versions

Bluetooth Core Specification Versions

• Why is It Called Bluetooth?

The developers of this wireless technology first used the name "Bluetooth" as a code name, but as time past, the name stuck.

The word "Bluetooth" is taken from the 10th century Danish King Harald Bluetooth. King Bluetooth had been influential in uniting Scandinavian Europe during an era when the region was torn apart by wars and feuding clans.

The founders of the Bluetooth SIG felt the name was fitting because:

1) Bluetooth technology was first developed in Scandinavia, and

2) Bluetooth technology is able to unite differing industries such as the cell phone, computing, and automotive markets. Bluetooth wireless technology simplifies and combines multiple forms of wireless communication into a single, secure, low-power, low-cost, globally available radio frequency.

• Where Did the Logo Come From?

A Scandinavian firm originally designed the logo at the time the SIG was formally introduced to the public. Keeping to the same origin as the Bluetooth name, the logo unites the Runic alphabetic characters "H", which looks similar to an asterisk, and a "B", which are the initials for Harald Bluetooth. If you look close enough you can see both embodied in the logo.

The Bluetooth Car

Bluetooth technology and its use in automobiles is becoming extremely popular in the United States. Many states have Laws Restricting Drivers from Using Cell Phones, thus making hands free calling a necessity. In Europe, similar laws exist, however Bluetooth technology is much more prevalent in cars and cell phones than in the U.S.

With legislation banning the use of cell phones while driving, car manufacturers have to find solutions to combat this problem. They are now looking at Bluetooth technology. Bluetooth is the perfect solution for this problem because it allows drivers to keep both hands on the steering wheel while simultaneously having conversations on their cell phones.

Vehicles can be enabled with Bluetooth hands free technology through various methods. There are standard or optional communications systems offered by automotive manufacturers, aftermarket car kits, wireless speakerphone accessories, and wireless headsets.

At the International Auto Show in Germany, October 2005, 22 automotive manufacturers worldwide, or more than 60% of the major car manufacturers surveyed, offered optional or standard Bluetooth communication systems in 61 different car models. The cars range from luxury models like Lexus, BMW, Acura, and Lincoln to more affordable cars like Toyota and Chrysler.

The new Acura TL offers Bluetooth wireless technology as part of its standard HandsFreeLink. To watch a demo from the Acura Website, please Click Here.

Not everyone who seeks the benefits of Bluetooth technology can afford a new car. Thankfully, there are other options through aftermarket kits. These kits usually require installation by professionals but offer most of the functionality of a factory installed Bluetooth kit. Please take a look at our section on Bluetooth Car Kits for more information.

The other option you have in order to enjoy Bluetooth hands free technology in your car is a Bluetooth Wireless Headset, which connects to your Bluetooth cell phone. With most Bluetooth headsets, you will still need to dial the phone number on your cell phone to make an outgoing call, but all incoming calls can be answered with a push of a button.

HISTORY OF BLUETOOTH :-

• The Bluetooth SIG

The name “Bluetooth” and its logo are trademarked by the privately held trade association named the Bluetooth Special Interest Group (SIG).

Founded in September 1998, the Bluetooth SIG is a unification of leaders in the telecommunications, computing, network, industrial automation, and Automotive industries. Today, the Bluetooth SIG is responsible for encouraging and supporting research and development in Bluetooth technology.

The Bluetooth SIG includes promoter member companies Microsoft, Ericsson, IBM, Intel, Agere, Motorola, Nokia, and Toshiba, plus thousands of Associate and Adopter member companies (BlueTomorrow.com's parent company, SP Commerce LLC, is a licensed and certified Adopter member of the Bluetooth SIG).

Bluetooth technology eliminates the need for wires that tangle our everyday lives. Streaming music and connecting devices are just a few of the powerful capabilities of Bluetooth technology. Let us teach you all about the wonderful world of Bluetooth.

Wireless transfer of large format entertainment data – music, video, and photos – between devices at short range is imminent. The Bluetooth Special Interest Group (SIG) today announced a new way it will provide for consumers’ growing need for speed.

The Bluetooth SIG is developing an innovative method of radio substitution. It will allow the well known Bluetooth protocols, profiles, security and pairing to be used in consumer devices while achieving faster throughput with momentary use of a secondary radio already present in the device. This architecture, called ‘Alternate MAC/PHY’ by Bluetooth SIG members working on the specification, is taking on a two-phased approach as SIG member companies drive the specification forward.

“This is the wireless technology equivalent of ‘low hanging fruit,’” said Michael Foley, Ph.D., executive director, the Bluetooth SIG. “What we’re doing is taking classic Bluetooth connections – using Bluetooth protocols, profiles, security and other architectural elements – and allowing it to jump on top of the already present 802.11 radio, when necessary, to send bulky entertainment data, faster. When the speed of 802.11 is overkill, the connection returns to normal operation on a Bluetooth radio for optimal power management and performance.”

In 2006, the Bluetooth SIG announced the selection of the WiMedia Alliance brand of ultra wideband technology as a high speed channel for Bluetooth technology. This development work continues between the two organizations in advance of widespread ultra wideband technology adoption – expected to be co-located in many Bluetooth devices. In the meantime, however, the SIG will make use of IEEE 802.11, a technology already present in many of the devices demanding greater speeds.

This two-phased roadmap for higher speeds will allow for a steady evolution in Bluetooth devices utilizing the presence of 802.11 today while continuing preparations for the presence of ultra wideband in the near future. “We’re committed to speedy wireless personal area network connections and we’ll always be looking for the best near term and long term way to accomplish that,” adds Foley. “The greatness of a generic alternate radio architecture being developed is that it’s adaptable.”

With the availability of high speed Bluetooth technology, device users can expect to move their entertainment data between their own devices and the trusted devices of friends, without the need for cables and wires. Some applications consumers will experience include:

• Wirelessly bulk synchronize music libraries between PC and MP3 player
• Bulk download photos to a printer or PC
• Send video files from camera or phone to computer or television

Meanwhile, Bluetooth devices will continue to offer the well known, low power and secure connections that make up the nearly 2 billion products already on the market. The core specification enabling the Alternate MAC/PHY is expected to be published to members in mid-2009 with work already well underway.

“The Bluetooth SIG is taking a logical step by applying Bluetooth protocols over an existing 802.11 radio to achieve efficient transfers of high data throughput applications," said Flint Pulskamp, wireless and mobile analyst at IDC. "Since Bluetooth and 802.11 already have significant traction in mobile devices, this coupled solution could prove to be an efficient interim solution, as the Bluetooth SIG continues to develop UWB for the future."

About the Bluetooth SIG
The Bluetooth Special Interest Group (SIG), comprised of leaders in the telecommunications, computing, consumer electronics, automotive and network industries, is driving development of Bluetooth wireless technology and bringing it to market. The Bluetooth SIG includes Promoter group companies Ericsson, Intel, Lenovo, Microsoft, Motorola, Nokia and Toshiba, along with over 10,000 Associate and Adopter member companies. The Bluetooth SIG, Inc. headquarters are located in Bellevue, Washington, U.S.A. For more information please visit www.bluetooth.com.

LIST OF BERMUDA TRIANGLE INCIDENTS

Aircraft Incidents

1940-1949

• TBF Avenger, 1942
• PBY Catalina, 1942
• TBF Avenger, 1943
• 4 US Navy Lockheed PV-1 Ventura's, 1943
• PB4Y Privateer, 1943
• PBY Catalina, 1944
• PB4Y Privateer, 1944
• SBD-5 Dauntless, 1944
• PBY-5A Catalina, 1944
• PB4Y Privateer, 1945
• B-24 Liberator, 1945
• US Navy Flight 19 (5 TBF Avengers), lost with 14 crewmen on December 5, 1945.
• US Navy PBM-5 Mariner, lost with 13 crewmen on December 5, 1945.
• US Army C-54 lost 100 miles off Bermuda, July 3, 1947.
• British South American Airways Avro Tudor IV Star Tiger, lost with 4 crewmen and 25 passengers on January 31, 1948 (aircraft lost near Bermuda.)
• Douglas DC-3 NC16002 lost with 3 crewmen and 29 passengers on December 27, 1948.
• British South American Airways Avro Tudor IV Star Ariel, lost with 7 crewmen and 13 passengers on January 17, 1949.

1950-1959

• F6F-5 Hellcat, lost in 1950.
• F9F-2 Panther, lost in 1950.
• US Air Force Globemaster lost (Refute: No C-74 or C-124 aircraft are reported lost in 1950 by the USAF.)
• British South American Airways Avro York transport, lost with 33 passengers and crew on February 2, 1952.
• C-46 Commando, lost in 1952.
• US Navy T2V SeaStar, lost in 1953.
• US Navy R7V-1 Super Constellation, lost with 2 pilots and 42 passengers on October 30, 1954
• US Navy P5M Marlin seaplane, lost with 10 crewmen on November 9, 1956.
• Beechcraft Bonanza N4952b, lost with 2 pilots on February 8, 1959. Thought to be near 31.25n 79.45w

1960-1969

• US Air Force F-100 Super Sabre, lost with pilot on March 18, 1960.
• US Air Force SAC B-52 bomber Pogo 22 lost with 4 crewmen on October 14, 1961.
• US Air Force KB-50 Aerial Tanker Tyler 41, lost with 8 crewmen on January 8, 1962.
• US Air Force C-133 Cargomaster, lost on May 27, 1962 .
• 2 US Air Force KC-135 Stratotankers, lost on August 28, 1963
• US Air Force C-133 Cargomaster, lost on September 22, 1963
• US Air Force C-119 Flying Boxcar, lost with 5 crewmen on June 5, 1965.
• Privately owned B-25 Mitchell, lost with pilot and 2 passengers on April 5, 1966.
• Military Chase YC-122, converted to civilian cargo plane, lost in 1967.
• Cessna 172, lost with pilot on June 6, 1969

1970-1979

• US Air Force F-4 Phantom II Sting 27, lost with 2 pilots on October 10, 1971 (F-4E of 307 TFS lost on a training mission.
• Ryan Navion, lost with 2 pilots on May 25, 1973.
• Piper Cherokee, lost with pilot and 5 passengers on July 13, 1974.
• US Navy KA-6D Fighting Tiger 524, lost with 2 pilots on February 22, 1978
• Argosy Airlines Douglas DC-3 Flight 902, registration number N407D, lost with 4 crewmen on September 21, 1978; vanished off radar scope.
• Caribbean Flight 912, lost on November 3, 1978 (The NTSB records this loss as happening on approach to the airport in St. Croix, US Virgin Islands)

1980-1989

• Beechcraft Baron N9027Q, lost with pilot on February 11, 1980

• ERCO Ercoupe N3808H, lost with pilot on June 28, 1980
• Beechcraft Bonanza, lost on January 6, 1981.
• Piper Cherokee N3527E, lost on March 26, 1986.

[edit] Prior to 1850

• 1779, Disappearance of Thomas Lynch, Jr. and wife while sailing to West Indies.
• 1780, General Gates; no British warship claimed her sinking, but she had been declared unseaworthy in 1779 and sold.
• August 8, 1800, USS Insurgent went missing during cruise to West Indies in search of enemy ships during Quasi-War with France. Insurgent was former French frigate L'Insurgente, captured the year before by USS Constellation.
• August 20, 1800, USS Pickering went missing on voyage to West Indies. Both Pickering and Insurgent may have been lost in a severe storm that hit West Indies on September 20, 1800.
• December 30, 1812 Patriot, American privateer. Carried as a passenger Theodosia Burr Alston, daughter of former U.S. Vice President Aaron Burr.
• October 1814, USS Wasp, sloop-of-war that severely harassed British shipping in the War of 1812; went missing on Caribbean cruise, October 1814.
• January/February 1815, USS Epervier, while carrying original peace proposals for War of 1812; left Algiers for Norfolk, and went missing with crew of 134 in 1815, delaying the ending of hostilities (rare instance of maritime disappearance directly connected to international politics). DANFS however says the ship went missing sometime after July 14, 1815, carrying copies of a treaty with the Dey of Algiers back to the US and may have been lost in a known August 1815 hurricane.
• January 1820, USS Lynx went missing with crew of 50 in far western Atlantic.
• October 1824, USS Wildcat went missing with crew of 31 after leaving Cuba (Navy records indicate she was a storm victim).
• 1840, Rosalie; went missing in Sargasso Sea.
• March 15, 1843, USS Grampus went missing sailing south of the Carolinas.

1850-1899

• December 4, 1872. Mary Celeste, brigantine commanded by Captain Benjamin Briggs, 7 crew plus Briggs' wife and daughter; found abandoned at sea west of the Azores.
• January 31, 1880. HMS Atalanta, 26-gun frigate; went missing with crew of 281 after departing Bermuda for Falmouth, England.

1900-1909

• November 14, 1909. Spray, ketch, piloted by renowned world-circumnavigator Joshua Slocum, went missing after departing Miami, Florid

1910-1919

• Mar 6-27, 1917. SS Timandra, 1,579-ton steam freighter, Captain Lee commanding; went missing with crew of 21 while bound for Buenos Aires from Norfolk for cargo of coal.
• Mar 6-10, 1918. USS Cyclops, collier, LT. CDR. George Worley; went missing with 309 crew and passengers after leaving Barbados for Baltimore, Maryland.

1920-1929

• November or December or September or Spaghetti, 1920, SS Hewitt, steam freighter. Disappeared.
• January 31, 1921, Carroll A. Deering, five-masted schooner, Captain W.B. Wormell, crew of 11. Found aground and abandoned at Diamond Shoals, near Cape Hatteras, North Carolina.
• December 1925, SS Cotopaxi, tramp steamer, Captain Meyers; went missing with crew of 32 after leaving Charleston, South Carolina for Havana, Cuba; reported caught in tropical storm.
• March 14, 1926, SS Suduffco, freighter, Captain Thomas J. Turner; went missing with crew of 29 while sailing from New York City to Los Angeles.
  

1930-1939

• March 1938, Anglo Australian, freighter, Captain Parslow; went missing with crew of 38 off Azores on voyage from Cardiff, Wales for British Columbia.

1940-1949

• February 18, 1942, FS Surcouf, submarine operated by Free French Navy lost in Caribbean, apparently rammed by freighter Thompson Lykes near Panama Canal; both vessels travelling unlit due to threat of U-boats.
• March 6, 1948, Evelyn K.
• 1948, SS Samkey (year also given as 1943) last position 41^o48' N 24^o W (NE of Azores).

1950-1959

• 1950, SS Sandra, freighter, lost after passing St. Augustine, Florida for Puerto Cabello, Venezuela
• January 13, 1955, Home Sweet Home, pleasure craft.
• September 26, 1955, Connemara IV, found abandoned.
• January 1, 1958, Revonoc, pleasure craft, captained by business tycoon Harvey Conover.

1960-1969

• February 3, 1963, SS Marine Sulphur Queen T-2 tanker, vanishes with crew of 39 off the Florida Keys; carrying molten sulphur. [2]
• July 2, 1963, Sno' Boy, pleasure craft, converted ACR (similar to WWII PT boats).
• January 13, 1965, Enchantress, pleasure craft.
• October 28, 1965, El Gato, pleasure craft.
• December 10 1967, Speed Artist, 5 persons; Windward Islands
• December 22, 1967, Witchcraft, cabin cruiser, 2 onboard, disappears one mile off Miami; had called Coast Guard requesting a tow, but on their arrival 19 minutes later no trace found; possibly pushed north by Gulf Stream; search involved 1,200 square miles

1970-1979

• 1970: French freighter Milton Latrides disappears; sailing from New Orleans to Cape Town; carrying vegetable oils and caustic soda
• El Caribe; lost on September 10, 1971
• 1973: German freighter Anita (20,000 tons), lost with crew of 32; sister ship Norse Variant (both carrying coal) lost at same time; year sometimes given as 1973; survivor from latter found on raft described loss of ship in stormy weather - waves broke hatch cover and ship sank quickly.
• Dawn; lost on April 22, 1975
• 1976: SS Sylvia L. Ossa lost in heavy seas 140 miles west of Bermuda.
• 1978: SS Hawarden Bridge had previously been found with marijuana residue by USCG Cape Knox February '78 [4], found abandoned in West Indies a month later[5]; crime might be involved. scuttled November '78.

1980-1989

• 1980: SS Poet; carrying grain to Egypt; no survivors.

1990-1999

• 1995: Inter-island freighter Jamanic K (built 1943) reported lost after leaving Cap Haitien.
• 1999: Freighter Genesis Lost after sailing from Port of Spain to St Vincent; cargo included 465 tons of water tanks, concrete slabs and bricks; reported problems with bilge pump before loss of contact. Search of 33,000 square miles of sea is fruitless.

The Bermuda Triangle, also known as the Devil's Triangle, is a region of the northwestern Atlantic Ocean in which a number of aircraft and surface vessels have disappeared. Some people have claimed that these disappearances fall beyond the boundaries of human error or acts of nature. Some of these disappearances have been attributed to the paranormal, a suspension of the laws of physics, or activity by extraterrestrial beings by popular culture.^[1] Though a substantial documentation exists showing numerous incidents to have been inaccurately reported or embellished by later authors, and numerous official agencies have gone on record as stating the number and nature of disappearances to be similar to any other area of ocean, many have remained unexplained despite considerable investigation.

The Triangle area

The area of the Triangle varies by author.

The boundaries of the Triangle vary with the author; some stating its shape is akin to a trapezoid covering the Straits of Florida, the Bahamas, and the entire Caribbean island area east to the Azores; others add to it the Gulf of Mexico. The more familiar, triangular boundary in most written works has as its points somewhere on the Atlantic coast of Florida; San Juan, Puerto Rico; and the mid-Atlantic island of Bermuda, with most of the accidents concentrated along the southern boundary around the Bahamas and the Florida Straits.

The area is one of the most heavily-sailed shipping lanes in the world, with ships crossing through it daily for ports in the Americas, Europe, and the Caribbean Islands. Cruise ships are also plentiful, and pleasure craft regularly go back and forth between Florida and the islands. It is also a heavily flown route for commercial and private aircraft heading towards Florida, the Caribbean, and South America from points north.

The Gulf Stream ocean current flows through the Triangle after leaving the Gulf of Mexico; its current of five to six knots may have played a part in a number of disappearances. Sudden storms can and do appear, and in the summer to late fall hurricanes strike the area. The combination of heavy maritime traffic and tempestuous weather makes it inevitable that vessels could founder in storms and be lost without a trace – especially before improved telecommunications, radar, and satellite technology arrived late in the 20th century.^[5]

History of the Triangle story

According to the Triangle authors, Christopher Columbus was the first person to document something strange in the Triangle, reporting that he and his crew observed "strange dancing lights on the horizon", flames in the sky, and at another point he wrote in his log about bizarre compass bearings in the area. From his log book, dated October 11, 1492 he wrote:

The land was first seen by a sailor (Rodrigo de Triana), although the Admiral at ten o'clock that evening standing on the quarter-deck saw a light, but so small a body that he could not affirm it to be land; calling to Pero Gutiérrez, groom of the King's wardrobe, he told him he saw a light, and bid him look that way, which he did and saw it; he did the same to Rodrigo Sánchez of Segovia, whom the King and Queen had sent with the squadron as comptroller, but he was unable to see it from his situation. The Admiral again perceived it once or twice, appearing like the light of a wax candle moving up and down, which some thought an indication of land. But the Admiral held it for certain that land was near...

Modern scholars checking the original log books have surmised that the lights he saw were the cooking fires of Taino natives in their canoes or on the beach; the compass problems were the result of a false reading based on the movement of a star.

The first article of any kind in which the legend of the Triangle began appeared in newspapers by E.V.W. Jones on September 16, 1950, through the Associated Press. Two years later, Fate magazine published "Sea Mystery At Our Back Door", a short article by George X. Sand in the October 1952 issue covering the loss of several planes and ships, including the loss of Flight 19, a group of five U.S. Navy TBM Avenger bombers on a training mission. Sand's article was the first to lay out the now-familiar triangular area where the losses took place. Flight 19 alone would be covered in the April 1962 issue of American Legion Magazine. The article was titled "The Lost Patrol", by Allen W. Eckert, and in his story it was claimed that the flight leader had been heard saying "We are entering white water, nothing seems right. We don't know where we are, the water is green, no white." It was also claimed that officials at the Navy board of inquiry stated that the planes "flew off to Mars." "The Lost Patrol" was the first to connect the supernatural to Flight 19, but it would take another author, Vincent Gaddis, writing in the February 1964 Argosy Magazine to take Flight 19 together with other mysterious disappearances and place it under the umbrella of a new catchy name: "The Deadly Bermuda Triangle";^[6] he would build on that article with a more detailed book, Invisible Horizons, the next year. Others would follow with their own works: John Wallace Spencer (Limbo of the Lost, 1969); Charles Berlitz (The Bermuda Triangle, 1974); Richard Winer (The Devil's Triangle, 1974), and many others, all keeping to some of the same supernatural elements outlined by Eckert.^[7]

Kusche's explanation

Lawrence David Kusche, a research librarian from Arizona State University and author of The Bermuda Triangle Mystery: Solved (1975) has challenged this trend. Kusche's research revealed a number of inaccuracies and inconsistencies between Berlitz's accounts and statements from eyewitnesses, participants, and others involved in the initial incidents. He noted cases where pertinent information went unreported, such as the disappearance of round-the-world yachtsman Donald Crowhurst, which Berlitz had presented as a mystery, despite clear evidence to the contrary. Another example was the ore-carrier Berlitz recounted as lost without trace three days out of an Atlantic port when it had been lost three days out of a port with the same name in the Pacific Ocean. Kusche also argued that a large percentage of the incidents which have sparked the Triangle's mysterious influence actually occurred well outside it. Often his research was surprisingly simple: he would go over period newspapers and see items like weather reports that were never mentioned in the stories.

Kusche came to several conclusions:

• The number of ships and aircraft reported missing in the area was not significantly greater, proportionally speaking, than in any other part of the ocean.
• In an area frequented by tropical storms, the number of disappearances that did occur were, for the most part, neither disproportionate, unlikely, nor mysterious; furthermore, Berlitz and other writers would often fail to mention such storms.
• The numbers themselves had been exaggerated by sloppy research. A boat listed as missing would be reported, but its eventual (if belated) return to port may not be reported.
• Some disappearances had in fact, never happened. One plane crash was said to have taken place in 1937 off Daytona Beach, Florida, in front of hundreds of witnesses; a check of the local papers revealed nothing.

Kusche concluded that:

The Legend of the Bermuda Triangle is a manufactured mystery… perpetuated by writers who either purposely or unknowingly made use of misconceptions, faulty reasoning, and sensationalism.^[8]

Other responses

The marine insurer Lloyd's of London has determined the Triangle to be no more dangerous than any other area of ocean, and does not charge unusual rates for passage through the region. United States Coast Guard records confirm their conclusion. In fact, the number of supposed disappearances is relatively insignificant considering the number of ships and aircraft which pass through on a regular basis.

The Coast Guard is also officially skeptical of the Triangle, noting that they collect and publish, through their inquiries, much documentation^[9] contradicting many of the incidents written about by the Triangle authors. In one such incident involving the 1972 explosion and sinking of the tanker V.A. Fogg in the Gulf of Mexico, the Coast Guard photographed the wreck and recovered several bodies^[10] despite one Triangle author stating that all the bodies had vanished, with the exception of the captain, who was found sitting in his cabin at his desk, clutching a coffee cup (Limbo of the Lost by John Wallace Spencer, 1973 edition).

The NOVA / Horizon episode The Case of the Bermuda Triangle (1976-06-27) was highly critical stating that "When we've gone back to the original sources or the people involved the mystery evaporates. Science does not have to answer questions about the Triangle because those questions are not valid in the first place. ... Ships and planes behave in the Triangle the same way they behave everywhere else in the world"^[11]

Skeptical researchers, such as Ernest Taves and Barry Singer, have noted how mysteries and the paranormal are very popular and profitable. This has led to the production of vast amounts of material on topics such as the Bermuda Triangle. They were able to show that some of the pro-paranormal material is often misleading or not accurate, but its producers continue to market it. They have therefore claimed that the market is biased in favour of books, TV specials, et cetera. which support the Triangle mystery and against well-researched material if it espouses a skeptical viewpoint.^[12]

Finally, if the Triangle is assumed to cross land, such as parts of Puerto Rico, the Bahamas, or Bermuda itself, there is no evidence for the disappearance of any land-based vehicles or persons. Located inside the Triangle, Freeport operates a major shipyard, an airport which yearly handles 50,000 flights and is visited by over a million tourists annually.

Natural explanations

Methane hydrates

Main article: Methane clathrate

Worldwide distribution of confirmed or inferred offshore gas hydrate-bearing sediments, 1996.
Source: USGS

False-color image of the Gulf Stream flowing north through the western Atlantic Ocean. (NASA)

An explanation for some of the disappearances has focused on the presence of vast fields of methane hydrates on the continental shelves. Laboratory experiments carried out in Australia have proven that bubbles can, indeed, sink a scale model ship by decreasing the density of the water^[13]; any wreckage consequently rising to the surface would be rapidly dispersed by the Gulf Stream. It has been hypothesized that periodic methane eruptions (sometimes called "mud volcanoes") may produce regions of frothy water that are no longer capable of providing adequate buoyancy for ships. If this were the case, such an area forming around a ship could cause it to sink very rapidly and without warning.

A white paper was published in 1981 by the United States Geological Survey about the appearance of hydrates in the Blake Ridge area, off the southeastern United States coast.^[14] However, according to a USGS web page, no large releases of gas hydrates are believed to have occurred in the Bermuda Triangle for the past 15,000 years.^[15]

Compass variations

Compass problems are one of the cited phrases in many Triangle incidents. Some have theorized the possibility of unusual local magnetic anomalies in the area, however these have not been shown to exist. It should also be remembered that compasses have natural magnetic variations in relation to the Magnetic poles. For example, in the United States the only places where magnetic (compass) north and geographic (true) north are exactly the same are on a line running from Wisconsin to the Gulf of Mexico. Navigators have known this for centuries. But the public may not be as informed and think there is something mysterious about the compass "changing" across an area as large as the Triangle, which it naturally will.

Hurricanes

Hurricanes are extremely powerful storms which are spawned in the Atlantic near the equator, and have historically been responsible for thousands of lives lost and billions of dollars in damage. The sinking of Francisco de Bobadilla's Spanish fleet in 1502 was the first recorded instance of a destructive hurricane. In 1988, Hurricane Gilbert, one of the most powerful hurricanes in history, set back Jamaica's economy by three years.^{[citation needed]} These storms have in the past caused a number of incidents related to the Triangle.

Gulf Stream

The Gulf Stream is an ocean current that originates in the Gulf of Mexico, and then through the Straits of Florida, into the North Atlantic. In essence, it is a river within an ocean, and like a river, it can and does carry floating objects. A small plane making a water landing or a boat having engine trouble will be carried away from its reported position by the current, as happened to the cabin cruiser Witchcraft on December 22, 1967, when it reported engine trouble near the Miami buoy marker one mile (1.6 km) from shore, but was not there when a Coast Guard cutter arrived.

Freak waves

Main article: Rogue wave (oceanography)

Extremely large waves can appear seemingly at random, even in calm seas. One such rogue wave caused the Ocean Ranger, then the world's largest offshore platform, to capsize in 1982. There is, however, no particular reason to believe rogue waves are more common in the Bermuda region, and this explanation cannot account for the loss of airplanes.

Acts of man

Human error

One of the most cited explanations in official inquiries as to the loss of any aircraft or vessel is human error. Whether deliberate or accidental, humans have been known to make mistakes resulting in catastrophe, and losses within the Bermuda Triangle are no exception. For example, the Coast Guard cited a lack of proper training for the cleaning of volatile benzene residue as a reason for the loss of the tanker V.A. Fogg in 1972. Human stubbornness may have caused businessman Harvey Conover to lose his sailing yacht, the Revonoc, as he sailed into the teeth of a storm south of Florida on January 1, 1958. It should be noted that many losses remain inconclusive due to the lack of wreckage which could be studied, a fact cited on many official reports.

Deliberate acts of destruction

This can fall into two categories: acts of war, and acts of piracy. Records in enemy files have been checked for numerous losses; while many sinkings have been attributed to surface raiders or submarines during the World Wars and documented in the various command log books, many others which have been suspected as falling in that category have not been proven; it is suspected that the loss of USS Cyclops in 1918, as well as her sister ships Proteus and Nereus in World War II, were attributed to submarines, but no such link has been found in the German records.

Piracy, as defined by the taking of a ship or small boat on the high seas, is an act which continues to this day. While piracy for cargo theft is more common in the western Pacific and Indian oceans, drug smugglers do steal pleasure boats for smuggling operations, and may have been involved in crew and yacht disappearances in the Caribbean. Historically famous pirates of the Caribbean (where piracy was common from about 1560 to the 1760s) include Edward Teach (Blackbeard) and Jean Lafitte. Lafitte is sometimes said to be a Triangle victim himself.

Another form of pirate operated on dry land. Bankers or wreckers would shine a light on shore to misdirect ships, which would then founder on the shore; the wreckers would then help themselves to the cargo. It is possible that these wreckers also killed any crew who protested. Nags Head, North Carolina, was named for the wreckers' practice of hanging a lantern on the head of a hobbled horse as it walked along the beach.

Popular theories

Triangle writers have used a number of supernatural theories to explain the events. One explanation pins the blame on leftover technology from the lost continent of Atlantis. Sometimes connected to the Atlantis story is the submerged rock formation known as the Bimini Road off the island of Bimini in the Bahamas, which is in the Triangle by some definitions. Followers of the purported psychic Edgar Cayce take his prediction that evidence of Atlantis would be found in 1968 or '69 as referring to the discovery of the Bimini Road. Believers describe the formation as a road, wall, or other structure, though geologists consider it to be of natural origin.^[16]

Other writers attribute the events to UFOs. This idea was used by Steven Spielberg for his film Close Encounters of the Third Kind, which features the lost Flight 19 as alien abductees.

Charles Berlitz, grandson of a distinguished linguist and author of various additional books on anomalous phenomena, has kept in line with this extraordinary explanation, and attributed the losses in the Triangle to anomalous or unexplained forces.^{[citation needed]}

Famous incidents

Main article: List of Bermuda Triangle incidents

Flight 19

US Navy TBF Grumman Avenger flight, similar to Flight 19. This photo had been used by various Triangle authors to illustrate Flight 19 itself. (US Navy)

Main article: Flight 19

Flight 19 was a training flight of TBM Avenger bombers that went missing on December 5, 1945 while over the Atlantic. The impression is given that the flight encountered unusual phenomena and anomalous compass readings, and that the flight took place on a calm day under the supervision of an experienced pilot, Lt. Charles Carroll Taylor. Adding to the intrigue is that the Navy's report of the accident was ascribed to "causes or reasons unknown." It is believed that Taylor's mother wanted to save her son's reputation, so she made them write "reasons unknown" when actually Taylor was 50 km NW from where he thought he was. ^[17]

While the basic facts of this version of the story are essentially accurate, some important details are missing. The weather was becoming stormy by the end of the incident; only Taylor had any significant flying time, but he was not familiar with the south Florida area and had a history of getting lost in flight, having done so three times during World War II, and being forced to ditch his planes twice into the water; and naval reports and written recordings of the conversations between Taylor and the other pilots of Flight 19 do not indicate magnetic problems.^[17]

Mary Celeste

The mysterious abandonment in 1872 of the Mary Celeste is often but inaccurately connected to the Triangle, the ship having been abandoned off the coast of Portugal. Many theories have been put forth over the years to explain the abandonment, including alcohol fumes from the cargo and insurance fraud. The event is possibly confused with the sinking of a ship with a similar name, the Mari Celeste, off the coast of Bermuda on September 13, 1864, which is mentioned in the book Bermuda Shipwrecks by Dan Berg.

Ellen Austin

The Ellen Austin supposedly came across an abandoned derelict, placed on board a prize crew, and attempted to sail with it to New York in 1881. According to the stories, the derelict disappeared; others elaborating further that the derelict reappeared minus the prize crew, then disappeared again with a second prize crew on board. A check of Lloyd's of London records proved the existence of the Meta, built in 1854; in 1880 the Meta was renamed Ellen Austin. There are no casualty listings for this vessel, or any vessel at that time, that would suggest a large number of missing men placed on board a derelict which later disappeared.^[18]

USS Cyclops

Main article: USS Cyclops (AC-4)

The incident resulting in the single largest loss of life in the history of the U.S. Navy not related to combat occurred when USS Cyclops under the command of Lieutenant Commander G. W. Worley, went missing without a trace with a crew of 306 sometime after March 4, 1918, after departing the island of Barbados. Although there is no strong evidence for any theory, storms, capsizing and enemy activity have all been suggested as explanations.^[19][20]

Theodosia Burr Alston

Main article: Theodosia Burr Alston

Theodosia Burr Alston was the daughter of former United States Vice President Aaron Burr. Her disappearance has been cited at least once in relation to the Triangle, in The Bermuda Triangle by Adi-Kent Thomas Jeffrey (1975). She was a passenger on board the Patriot, which sailed from Charleston, South Carolina to New York City on December 30, 1812, and was never heard from again. Both piracy and the War of 1812 have been posited as explanations, as well as a theory placing her in Texas, well outside the Triangle.

Spray

Main article: Spray (sailing vessel)

Captain Joshua Slocum's skill as a mariner was beyond argument; he was the first man to sail around the world solo. In 1909, in his boat Spray he set out on a course to take him through the Caribbean to Venezuela. He disappeared; there was no evidence he was even in the Triangle when Spray was lost. It was assumed he was run down by a steamer or struck by a whale, the Spray being too sound a craft and Slocum too experienced a mariner for any other cause to be considered likely, and in 1924 he was declared legally dead. While a mystery, there is no known evidence for, or against, paranormal activity.

Carroll A. Deering

Main article: Carroll A. Deering

Schooner Carroll A. Deering, as seen from the Cape Lookout lightship on January 29, 1921, two days before she was found deserted in North Carolina. (US Coast Guard)

A five-masted schooner built in 1919, the Carroll A. Deering was found hard aground and abandoned at Diamond Shoals, near Cape Hatteras, North Carolina on January 31, 1921. Rumors and more at the time indicated the Deering was a victim of piracy, possibly connected with the illegal rum-running trade during Prohibition, and possibly involving another ship, S.S. Hewitt, which disappeared at roughly the same time. Just hours later, an unknown steamer sailed near the lightship along the track of the Deering, and ignored all signals from the lightship. It is speculated that the Hewitt may have been this mystery ship, and possibly involved in the Deering crew's disappearance.^[21]

Douglas DC-3

Main article: NC16002 disappearance

On December 28, 1948, a Douglas DC-3 aircraft, number NC16002, disappeared while on a flight from San Juan, Puerto Rico, to Miami. No trace of the aircraft or the 32 people onboard was ever found. From the documentation compiled by the Civil Aeronautics Board investigation, a possible key to the plane's disappearance was found, but barely touched upon by the Triangle writers: the plane's batteries were inspected and found to be low on charge, but ordered back into the plane without a recharge by the pilot while in San Juan. Whether or not this led to complete electrical failure will never be known. However, since piston-engined aircraft rely upon magnetos to provide electrical power and spark to their cylinders rather than batteries, this theory is unlikely.^[22]

Star Tiger and Star Ariel

Main article: Star Tiger and Star Ariel

These Avro Tudor IV passenger aircraft disappeared without trace en route to Bermuda and Jamaica, respectively. Star Tiger was lost on January 30, 1948 on a flight from the Azores to Bermuda. Star Ariel was lost on January 17, 1949, on a flight from Bermuda to Kingston, Jamaica. Neither aircraft gave out a distress call; in fact, their last messages were routine. A possible clue to their disappearance was found in the mountains of the Andes in 1998: the Star Dust, an Avro Lancastrian airliner run by the same airline, had disappeared on a flight from Buenos Aires, Argentina, to Santiago, Chile on August 2, 1947. The plane's remains were discovered at the melt end of a glacier, suggesting that either the crew did not pay attention to their instruments, suffered an instrument failure or did not allow for headwind effects from the jetstream on the way to Santiago when it hit a mountain peak, with the resulting avalanche burying the remains and incorporating it into the glacier. However, this is mere speculation with regard to the Star Tiger and Star Ariel, pending the recovery of the aircraft. It should be noted that the Star Tiger was flying at a height of just 2,000 feet (610 m), which would have meant that if the plane was forced down, there would have been no time to send out a distress message. It is also far too low for the jetstream or any other high-altitude wind to have any effect.^[23]

KC-135 Stratotankers

On August 28, 1963 a pair of U.S. Air Force KC-135 Stratotanker aircraft collided and crashed into the Atlantic. The Triangle version (Winer, Berlitz, Gaddis) of this story specifies that they did collide and crash, but there were two distinct crash sites, separated by over 160 miles (260 km) of water. However, Kusche's research showed that the unclassified version of the Air Force investigation report stated that the debris field defining the second "crash site" was examined by a search and rescue ship, and found to be a mass of seaweed and driftwood tangled in an old buoy.

SS Marine Sulphur Queen

Main article: SS Marine Sulphur Queen

SS Marine Sulphur Queen, a T2 tanker converted from oil to sulfur carrier, was last heard from on February 4, 1963 with a crew of 39 near the Florida Keys. Marine Sulphur Queen was the first vessel mentioned in Vincent Gaddis' 1964 Argosy Magazine article, but he left it as having "sailed into the unknown", despite the Coast Guard report which not only documented the ship's badly-maintained history, but declared that it was an unseaworthy vessel that should never have gone to sea.^[24][25]

Raifuku Maru

One of the more famous incidents in the Triangle took place in 1921 (some say a few years later), when the Japanese vessel Raifuku Maru (sometimes misidentified as Raikuke Maru) went down with all hands after sending a distress signal which allegedly said "Danger like dagger now. Come quick!", or "It's like a dagger, come quick!" This has led writers to speculate on what the "dagger" was, with a waterspout being the likely candidate (Winer). In reality the ship was nowhere near the Triangle, nor was the word "dagger" a part of the ship's distress call ("Now very danger. Come quick."); having left Boston for Hamburg, Germany, on April 21, 1925, she got caught in a severe storm and sank in the North Atlantic with all hands while another ship, RMS Homeric, attempted an unsuccessful rescue.^[26]

Connemara IV

A pleasure yacht found adrift in the Atlantic south of Bermuda on September 26, 1955; it is usually stated in the stories (Berlitz, Winer) that the crew vanished while the yacht survived being at sea during three hurricanes. The 1955 Atlantic hurricane season lists only one storm coming near Bermuda towards the end of August, hurricane "Edith"; of the others, "Flora" was too far to the east, and "Katie" arrived after the yacht was recovered. It was confirmed that the Connemara IV was empty and in port when "Edith" may have caused the yacht to slip her moorings and drift out to sea.^{[citation needed]}

[edit] List

Rank	City	State	Population [1]
1	Mumbai (Bombay) with Navi Mumbai &Thane	Maharashtra	20,870,764
2	Delhi	Delhi	18,362,625
3	Kolkata (Calcutta)	West Bengal	15,185,670
4	Chennai (Madras)	Tamil Nadu	7,196,555
5	Hyderabad	Andhra Pradesh	6,762,214[2][3]
6	Bengaluru(Bangalore)	Karnataka	6,370,137
7	Ahmedabad	Gujarat	5,680,566
8	Pune	Maharashtra	5,069,061
9	Kanpur	Uttar Pradesh	3,408,945
10	Surat	Gujarat	3,149,269
11	Jaipur	Rajasthan	2,997,114
12	Lucknow	Uttar Pradesh	2,915,756
13	Nagpur	Maharashtra	2,531,567
14	Patna	Bihar	2,516,346
15	Indore	Madhya Pradesh	1,994,909
16	Meerut	Uttar Pradesh	1,831,078
17	Bhopal	Madhya Pradesh	1,713,383
18	Vadodara (Baroda)	Gujarat	1,671,713
19	Ludhiana	Punjab	1,662,325
20	Nashik	Maharashtra	1,656,359
21	Bhubaneswar & Cuttack	Orissa	1,636,216
22	Agra	Uttar Pradesh	1,630,400
23	Coimbatore	Tamil Nadu	1,619,778
24	Kochi (Cochin)	Kerala	1,518,261
25	Visakhapatnam	Andhra Pradesh	1,489,211
26	Varanasi	Uttar Pradesh	1,487,556
27	Nashik	Maharashtra	1,459,589
28	Rajkot	Gujarat	1,432,180
29	Madurai	Tamil Nadu	1,338,206
30	Asansol	West Bengal	1,287,931
31	Jabalpur	Madhya Pradesh	1,251,434
32	Allahabad	Uttar Pradesh	1,243,649
33	Jamshedpur	Jharkhand	1,234,188
34	Dhanbad	Jharkhand	1,192,242
35	Amritsar	Punjab	1,181,790
36	Mysore	Karnataka	1,164,323
37	Aurangabad	Maharashtra	1,153,825
38	Vijayawada	Andhra Pradesh	1,132,644
39	Sholapur	Maharashtra	1,094,553
40	Srinagar	Jammu and Kashmir	1,088,067
41	Bhilai	Chhattisgarh	1,083,372
42	Ranchi	Jharkhand	1,039,692
43	Thiruvananthapuram (Trivandrum)	Kerala	1,027,403
44	Guwahati	Assam	1,012,811
45	Chandigarh	Chandigarh	1,003,301
46	Kozhikode (Calicut)	Kerala	985,922
47	Gwalior	Madhya Pradesh	972,578
48	Jodhpur	Rajasthan	971,407
49	Tiruchchirappalli	Tamil Nadu	948,915
50	Jalandhar	Punjab	934,511
51	Bareilly	Uttar Pradesh	888,045
52	Hubli	Karnataka	879,506
53	Aligarh	Uttar Pradesh	823,085
54	Kota	Rajasthan	807,920
55	Moradabad	Uttar Pradesh	785,105
56	Raipur	Chhattisgarh	783,282
57	Dehradun	Uttarakhand	709,240
58	Gorakhpur	Uttar Pradesh	707,516
59	Jammu	Jammu and Kashmir	680,651
60	Warangal	Andhra Pradesh	646,541
61	Amravati	Maharashtra	646,416
62	Jamnagar	Gujarat	625,562
63	Bikaner	Rajasthan	612,699
64	Tiruppur	Tamil Nadu	608,004
65	Mangalore	Karnataka	603,269
66	Sangli-Miraj	Maharashtra	601,214
67	Bhavnagar	Gujarat	600,559
68	Ajmer	Rajasthan	596,023
69	Bokaro	Jharkhand	579,990
70	Belgaum	Karnataka	567,060
71	Puducherry(Pondicherry)	Puducherry	566,478
72	Kannur	Kerala	558,032
73	Kolhapur	Maharashtra	557,336
74	Siliguri	West Bengal	556,125
75	Rourkela	Orissa	542,481
76	Guntur	Andhra Pradesh	540,244
77	Durgapur	West Bengal	538,306
78	Nanded	Maharashtra	529,145
79	Kalburgi (Gulbarga)	Karnataka	521,492
80	Jhansi	Uttar Pradesh	518,945

The Status of Indian cities comprises two ranking systems used by the Government of India to allocate compensatory allowances to the cities in the country. The list classifies cities in India based on two parameters — Compensatory City Allowance (CCA), further divided into categories A-1, A, B-1 and B-2, and House Rent Allowance (HRA), further divided into categories A-1, A, B-1, B-2 and C. This classification was initially based on the recommendations of the Fifth Pay Commission of India (1997). City statuses were later revised based on the results of the 2001 Census of India. The following list classifies 50 Indian cities based on their CCA and HRA statuses.

A

• Abohar
• Abu Road
• Adilabad
• Ariyalur
• Agartala*
• Agra
• Ahmedabad
• Ahmednagar
• Aizwal*
• Ajmer
• Ajjampura
• Akola
• Aligarh
• Allahabad
• Alala
• Alwar
• Ambala
• Amber
• Amravati
• Amreli
• Amritsar
• Anakapalle
• Anand
• Anantapur
• Anklesvar (Ankleshwar)
• Anuppur
• Araria
• Arcot
• Arrah
• Aruppukkottai
• Asansol
• Ashok Nagar
• Aurangabad
• Auroville
• Ayodhya
• Azamgarh

• Baharampur
• Bahraich
• Balaghat
• Balasore
• Balia
• Balrampur
• Banda
• Banga (City)
• Bengaluru* (Bangalore)
• Banganapalle
• Banswara
• Banur
• Bardhaman (Burdwan)
• Bareilly
• Baripada
• Barmer
• Barrackpur
• Barwani
• Banswara
• Beawar
• Belgaum
• Bellary
• Betul
• Bhagalpur
• Bhavani
• Bhandara
• Bharatpur
• Bharuch
• Bhavnagar
• Bhilai Nagar
• Bhind
• Bhiwandi
• Bhopal*
• Bhubaneswar*
• Bhuj
• Bidar
• Bihar Sharif
• Bijapur
• Bijnaur, UP
• Bikaner
• Bilaspur, Chhattisgarh
• Bilaspur, Himachal Pradesh
• Bilgha, Punjab
• Bodh Gaya
• Bokaro Steel City
• Buldana
• Burhanpur
• Buxar
• Bulandshahr
• Barh
• Bangalore
• Ballarpur

C

• Kozhikode* (formerly Calicut)
• Cambay (Khambat)
• Chamoli Gopeshwar
• Champawat
• Chamrajnagar
• Chandannagar
• Chandigarh
• Chapra
• Charkhari
• Chandrapur
• Chengalpattu
• Chennai* (formerly Madras)
• Chhatarpur
• Chhindwara
• Chikmagalur
• Chiplun
• Chitradurga
• Chitrakoot Dham Karwi
• Chittoor
• Coimbatore
• Contai
• Coonoor
• Cuddalore
• Cuddapah
• Cuttack (CAtti)

D

• Dabra
• Dadra
• Dahod
• Dakshineswar in North Calcutta
• Daltonganj
• Daman
• Damoh
• Darbhanga
• Darjeeling
• Datia
• Davanagere
• Dehgam
• Dehradun*
• Deoghar
• Dewas
• Delhi
• Dhanbad
• Dhar
• Dharampur
• Dharamsala
• Dharwad
• Dholka
• Dhule
• Dhulian
• Dispur*
• Dindigul
• Diu
• Dombivli
• Duhbai
• Dumdum
• Durg
• Durgapur
• Dwarka
• Sudama Chand

E

• Ernakulam
• Erode
• Etah
• Etawah

[edit] F

• Faizabad
• Faridabad
• Faridkot
• Farrukhabad
• Fatehgarh
• Fatehpur Sikri
• Ferozepur
• Firozabad

G

• Greater Noida
• Gwalior
• Gadchiroli
• Gandhinagar*
• Gangtok*
• Ganjam
• Garcha, Punjab*
• Gaya
• Ghaziabad
• Ghazipur
• Goa Velha
• Godhra
• Gondiya
• Gorakhpur
• Gulbarga
• Gumla
• Guna
• Gundlupet
• Guntur
• Gurgaon
• Guwahati
• Gudalur
• Gudivada
• Gwalior

H

• Hoshiarpur
• Haldia
• Haldwani
• Hamirpur, Himachal Pradesh
• Hamir, Uttar Pradesh
• Hanumangarh
• Howrah
• Harda
• Harsawa
• Haridwar
• Hubli
• Hassan
• Hastinapur
• Hathras
• Himatnagar
• Hisar
• Hansi
• Hyderabad, Andhra Pradesh*

I

• Indore
• Irinjalakuda

J

• Jabalpur
• Jaipur*
• Jais
• Jaisalmer
• Jalandhar
• Jalgaon
• Jagraon
• Jammu
• Jamnagar
• Jamshedpur
• Jaunpur
• Jhabua
• Jhalawar
• Jhansi
• Jhunjhunu
• Jodhpur
• Jorhat
• Junagadh

K

• Kakinada
• Kalimpong
• Kalwa
• Kalyan-Dombivali
• Kalyani
• Kanauj
• Kancheepuram
• Kandla
• Kangazha
• Kannur
• Kanpur
• Kanyakumari
• Karaikal
• Karaikudi
• Karimnagar
• Karjat
• Karnal
• Karur
• Karwar
• Kavaratti*
• Khammam
• Khandwa
• Kharagpur
• Khargone
• Kheda
• Khilchipur
• Khuldabad
• Kirandul
• Kochi (formerly Cochin)
• Kohima*
• Kolhapur
• Kolar
• Kolhapur
• Kolkata* (formerly Calcutta)
• Kollam (formerly Quilon)
• Konark
• Korba
• Kota
• Kotdwara
• Kothagudem
• Kottarakara
• Kottayam
• Kovilpatti
• Koyampattur
• Kozhencherry
• Kozhikode (formerly Calicut)
• Kulpahar
• Kumbakonam
• Kumbhraj
• Kurnool
• Kushinagar
• Karamsad
• Kothamangalam

L

• Lalitpur
• Leh
• Lucknow*
• Ludhiana

M

• Madanapalle
• Madgaon
• Madikeri (Mercara)
• Madurai
• Mahabaleswar
• Mahabubnagar
• Mahe
• Mahoba (Ancient Name Mahotsav Nagar)
• Mahwa
• Majri, Punjab
• Mandla
• Mandsaur
• Mangalagiri
• Mangalore
• Mapusa
• Marmagao
• Mathura
• Machilipatnam
• Meerut
• Mirzapur
• Mohali
• Moradabad
• Motihari
• Mount Abu
• Mullanpur
• Mumbai* (formerly Bombay)
• Mussoorie
• Murwara (Katni)
• Murshidabad
• Muzaffarnagar*
• Muzaffarpur
• Mysore
• Mokama

N

• Nadiad
• Nagapattinam
• Nagarkurnool
• Nagercoil
• Nagina, UP
• Nagpur
• Nainital
• Nalgonda
• Nanded
• Nandyal
• Nandurbar
• Narasaraopet
• Narsimhapur
• Narsinghgarh
• Nashik
• Navi Mumbai (New Mumbai)
• Navsari
• Nawalgarh
• Neemuch
• Nellore
• New Delhi* or Delhi
• New Guntur
• Nizamabad
• NOIDA (Gautam Budh Nagar)
• Nanital
• Nurmahal, Punjab
• Nurpur, Himachal Pradesh

O

• Ootacamund or Ooty (Udhagamandalam)
• Ongole
• Orai
• Osmanabad

P

• Palanpur
• Panaji* ("Panjim")
• Panchkula
• Pandharpur
• Panipat
• Panna
• Pasla, Punjab
• Patan
• Pathankot
• Patiala
• Patna*
• Patratu,Jharkhand
• Pimpri Chinchwad
• Ponda
• Puducherry* (formerly Pondicherry)
• Porbandar
• Port Blair*
• Pune
• Puri
• Pushkar
• Palghat
• Punalur
• Pratapgarh

Q

• Quilon (now Kollam)

R

• Raichur
• Raigarh
• Raisen
• Raipur
• Rajgarh
• Rajkot
• Rajnandgaon
• Ramanathapuram
• Rameshwaram
• Rampur
• Rampur
• Ratangarh
• Ratlam
• Ratnagiri
• Raurkela
• Rae Bareli

S

• Sagars
• Salem
• Samastipur
• Sanawad
• Sangli
• Sangamner
• Sathyamangalam
• Satara
• Satna
• Saharanpur
• Sehore
• Seoni
• Shajapur
• Shegaon
• Sheopur
• Shevgaon
• Shillong
• Shivpuri
• Shivani (in Chikmagalur District, Karnataka)
• Sholapur
• shrirampur
• shrigonda
• Siddipet
• Sikar
• Silchar
• Silvassa
• Sindhanur
• Shimla
• Shimoga
• Shirala
• Siliguri
• Singrauli
• Sirohi
• Sironj
• Sitamarhi
• Siwan
• Sonipat
• Sriganganagar
• Srikakulam
• Srinagar
• Surat
• Suratgarh
• Surendranagar
• Sitapur

T

• Tamluk
• Tandur
• Tenali
• Thane
• Thanjavur
• Thathawata
• Thiruvallur
• Thrikkannamangal
• Thrissur(formerly Trichur)
• Thoothukudi, (formerly Tuticorin)
• Tinsukia
• Tirupattur* (formerly Tirupattur)
• Tiruchirappalli
• Tirunelveli
• Tirupathi
• Tirupur
• Tikamgarh
• Thiruvananthapuram* (formerly Trivandrum)

U

• Udaipur in Rajasthan
• Udaipur in Tripura
• Udhampur in Jammu & Kashmir
• Udupi(Udipi)
• Udhagamandalam (formerly Ootacamund or Ooty)
• Ujjain
• Ulhasnagar
• Unnao
• Uttarpara in West Bengal

V

• Vadodara
• Vallabh Vidhyanagar
• Valsad
• Vandavasi
• Vapi
• Varanasi (aka Banaras, Kashi)
• Vasai
• Vasco da Gama, Goa
• Vellore
• Vidisha
• Vijayawada
• Viluppuram
• Virar
• Visakhapatnam
• Vizianagaram
• Virudhachalam
• Vyara

W

• Warangal
• Wardha
• Wani
• Wayanad

Y

• Yavatmal
• Yanam
• Yamuna Nagar