companies left this port open on the firewall to meet their standard busi- ness needs. Doing so also forced the developer to write the packet data in an HTML format to trick the firewall into believing the information was a valid response to a client request via HTTP and required a server applica- tion to intercept and interpret the packet of information. It was difficult to use port 80 because you needed to create a proprietary port-80 listener on the  server,  which  was  often  banned  (wisely,  in  our  opinion)  by  network administrators. Another trick was to use the FTP protocol as a transport mechanism for communication between client and server applications. The FTP protocol was standard, and most companies left ports 20 and 21 open for FTP com- munication, making it fairly easy to create a file and send it to a host FTP server. An application on the server would be responsible for grabbing the file, opening  it,  parsing  the  contents,  and  processing  the  information.  Once again, this process involved the use of the Winsock, or equivalent, control for  TCP/IP  capability.  And  that  suffered  the  same  problem  as  using HTTP—you needed to provide your own listener that had to run on the server. The Lineage of Web Services TCP/IP began as a low-budget development effort pioneered by an associ- ation of allied researchers for the promotion of United States Department of Defense Advanced Research Projects Agency Network (ARPAnet) and was instituted in 1975. It has since progressed to a worldwide standard, recognized for bringing to life the first-tier electronic peer-to-peer commu- nication process known as TCP/IP. For this reason, the TCP/IP protocol is ultimately responsible for spearheading the influence for the development of many of the previously mentioned second-tier protocols, as well as the creation of SOAP. Unlike its sidekick, the UDP  protocol, TCP  offers a reliable manner in which  to  exchange  true  client/server  information.  UDP,  developed  as  a one-way  protocol,  is  responsible  for  simply  broadcasting  messages  to  a host system without binding, also known as handshaking, with it. A UDP packet is simply broadcasted to an IP address and, optionally, a port, so it never physically binds to a host TCP/IP server and therefore never returns a response code to the user who initiated the broadcasted message. Thus, the initiator cannot be 100 percent certain that the request made it to the server unless an additional request is sent to query for the answer. Also, because the UDP protocol never binds to the server, IP addresses are 8 Chapter 1