Unit-5: Visual programming lecture notes (Advanced Concepts)

Unit-5: Visual programming lecture notes (Advanced Concepts) in Visual programming uploaded at P.R.Engineering college

Unit-5: Visual programming lecture notes (Advanced Concepts) in Visual programming at P.R.Engineering college uploaded by P.R.Engineering college Staff in lecturenotes.net

Summary / document preview text:

INTRODUCTION

This unit introduces the readers with advanced concepts and programming. This unit starts with a primer on the Domain Name System and the working of HyperText Transport Protocol (HTTP). Then it’s time to get something running.Also this unit enables the readers to understand and work with status bars, splitter windows and dynamic link libraries. The unit provides an introduction to client-side database access systems: Open Database Connectivity (ODBC) and Data Access Objects (DAO). Finally it helps the readers to understand and program the Winsock and WinInet classes.

LEARNING OBJECTIVES

1. Learn the fundamentals to internet programming
2. Programming the status bars and splitter window
3. Learn to create DLL and embedding them to regular windows programs
4. Write C++ database applications for Microsoft Windows
5. Study an HTTP client-server program based on Winsock and WinInet
6. Learn about the Microsoft’sActiveX technology

THE DOMAIN NAME SYSTEM

Domain Name System (DNS) is an industry-standard protocol used to locate computers on an IP-based network. Users can remember display names, such as www.microsoft.com easier than number-based addresses, such as 207.46.131.137.
IP networks, such as the Internet and Windows networks, rely on number-based addresses to transmit data throughout the network; therefore, it is necessary to translate display names (such as www.microsoft.com) into numeric addresses that the network can recognize (such as 207.46.131.137). DNS is the service of choice in Windows to locate such resources and translate them into IP addresses.

DNS is the primary locator service for Active Directory, and therefore, DNS can be considered a base service for both Windows and Active Directory. Windows provides functions that enable application programmers to use DNS functions such as programmatically making DNS.
  Although TCP/IP uses IP addresses to locate and connect to hosts (computers and other TCP/IP network devices), users typically prefer to use friendly names. For example, users prefer the friendly name ftp.reskit.com, instead of its IP address, 172.16.23.55. The Domain Name System (DNS), defined in RFCs 1034 and 1035, is used on the Internet to provide a standard naming convention for locating IP-based computers.

On the Internet, before the implementation of DNS, the use of names to locate resources on TCP/IP networks was supported by a file called Hosts. Network administrators entered names and IP addresses into Hosts, and computers used the file for name resolution.

Both the Hosts file and DNS use a namespace. A namespace is a grouping in which names can be used to symbolically represent another type of information, such as an IP address, and in which specific rules are established that determine how names can be created and used. Some namespaces, such as DNS, are hierarchically structured and provide rules that allow for the namespace to be divided into subsets of names for distributing and delegating parts of the namespace. Other namespaces, such as the Hosts namespace cannot be divided and must be distributed in their entirety. Because of this, using the Hosts file posed a problem for network administrators. As the number of computers and users on the Internet grew, the task of updating and distributing the Hosts file became unmanageable.

DNS replaces the Hosts file with a distributed database that implements a hierarchical naming system. This naming system allows for growth on the Internet and the creation of names that are unique throughout the Internet and private TCP/IP-based intranets.

Elements of the DNS

The DNS has three major components: 1) DOMAIN NAME SPACE and RESOURCE RECORDS, 2) NAME SERVERS and 3) RESOLVERS. These three components roughly correspond to the three layers or views of the domain system.

The DOMAIN NAME SPACE and RESOURCE RECORDS

The DOMAIN NAME SPACE and RESOURCE RECORDS, which are specifications for a tree structured name space and data associated with the names. Conceptually, each node and leaf of the domain name space tree names a set of information, and query operations are attempts to extract specific types of information from a particular set. A query names the domain name of interest and describes the type of resource information that is desired. For example, the Internet uses some of its domain names to identify hosts; queries for address resources return Internet host addresses.

The following figure 5.1 shows a part of the current domain name space. Note that the tree is a very small subset of the actual name space.
 
In this example, the root domain has three immediate subdomains: MIL, EDU, and ARPA. The LCS.MIT.EDU domain has one immediate subdomain named XX.LCS.MIT.EDU. All of the leaves are also domains.

A domain name identifies a node. Each node has a set of resource information, which may be empty. The set of resource information associated with a particular name is composed of separate resource records (RRs). The order of RRs in a set is not significant, and need not be preserved by name servers, resolvers, or other parts of the DNS. RRs are represented in binary form in the packets of the DNS protocol, and are usually represented in highly encoded form when stored in a name server or resolver.

Name Servers

Name Servers are server programs which hold information about the domain tree’s structure and set information. Aname server may cache structure or set information about any part of the domain tree, but in general a particular name server has complete information about a subset of the domain space, and pointers to other name servers that can be used to lead to information from any part of the domain tree.
 
While name servers can have several optional functions and sources of data, the essential task of a name server is to answer queries using data in its zones. By design, name servers can answer queries in a simple manner; the response can always be generated using only local data, and either contains the answer to the question or a referral to other name servers “closer” to the desired information.

Name servers know the parts of the domain tree for which they have complete information; a name server is said to be an AUTHORITY for these parts of the name space. Authoritative information is organized into units called ZONEs, and these zones can be automatically distributed to the name servers which provide redundant service for the data in a zone.

A given zone will be available from several name servers to insure its availability in spite of host or communication link failure. By administrative fiat, we require every zone to be available on at least two servers, and many zones have more redundancy than that.

A given name server will typically support one or more zones, but this gives it authoritative information about only a small section of the domain tree. It may also have some cached non-authoritative data about other parts of the tree. The name server marks its responses to queries so that the requester can tell whether the response comes from authoritative data or not.
Resolvers

Resolvers are programs that extract information from name servers in response to client requests. Resolvers must be able to access at least one name server and use that name server’s information to answer a query directly, or pursue the query using referrals to other name servers. Aresolver will typically be a system routine that is directly accessible to user programs; hence no protocol is necessary between the resolver and the user program.

In the simplest case, a resolver receives a request from a user program (e.g., mail programs, TELNET, FTP) in the form of a subroutine call, system call etc., and returns the desired information in a form compatible with the local host’s data formats.

The resolver is located on the same machine as the program that requests the resolver’s services, but it may need to consult name servers on other hosts. Because a resolver may need to consult several name servers, or may have the requested information in a local cache, the amount of time that a resolver will take to complete can vary quite a bit, from milliseconds to several seconds.

A very important goal of the resolver is to eliminate network delay and name server load from most requests by answering them from its cache of prior results. It follows that caches which are shared by multiple processes, users, machines, etc., are more efficient than non-shared caches.
 
WORLD WIDE WEB (HTTP)

HTTP stands for Hypertext Transfer Protocol. It’s the network protocol used to deliver virtually all files and other data (collectively called resources) on the World Wide Web, whether they’re HTML files, image files, query results, or anything else. Usually, HTTP takes place through TCP/IP sockets.

A browser is an HTTP client because it sends requests to an HTTP server (Web server), which then sends responses back to the client. The standard (and default) port for HTTP servers to listen on is 80, though they can use any port.

HTTP is used to transmit resources, not just files. A resource is some chunk of information that can be identified by a URL (it’s the R in URL). The most common kind of resource is a file, but a resource may also be a dynamically-generated query result, the output of a CGI script, a document that is available in several languages, or something else.

While learning HTTP, it may help to think of a resource as similar to a file, but more general. As a practical matter, almost all HTTP resources are currently either files or server- side script output.

Structure of HTTP Transactions

Like most network protocols, HTTP uses the client-server model: An HTTP client opens a connection and sends a request message to an HTTP server; the server then returns a response message, usually containing the resource that was requested. After delivering the response, the server closes the connection (making HTTP a stateless protocol, not maintaining any connection information between transactions).

The formats of the request and response messages are similar, and English-oriented.

Both kinds of messages consist of:
• an initial line,
• zero or more header lines,
• a blank line (i.e. a CRLF by itself), and
• an optional message body (e.g. a file, or query data, or query output).

Put another way, the format of an HTTP message is:
<initial> Header1: value1
Header2: value2 Header3: value3
<optional>
  
Initial lines and headers should end in CRLF, though you should gracefully handle lines ending in just LF. (More exactly, CR and LF here mean ASCII values 13 and 10, even though some platforms may use different characters.)
Initial Request Line

The initial line is different for the request than for the response. A request line has three parts, separated by spaces: a method name, the local path of the requested resource, and the version of HTTP being used.A typical request line is:
GET /path/to/file/index.html HTTP/1.0

• GET is the most common HTTP method; it says “give me this resource”. Other methods include POST and HEAD. Method names are always uppercase.
• The path is the part of the URL after the host name, also called the request URI (a URI is like a URL, but more general).
• The HTTP version always takes the form “HTTP/x.x”, uppercase.
  Initial Response Line (Status Line)

The initial response line, called the status line, also has three parts separated by spaces: the HTTP version, a response status code that gives the result of the request, and an English reason phrase describing the status code. Typical status lines are:
HTTP/1.0 200 OK
or
HTTP/1.0 404 Not Found
• The HTTP version is in the same format as in the request line, “HTTP/x.x”.
• The status code is meant to be computer-readable; the reason phrase is meant to be human-readable, and may vary.
• The status code is a three-digit integer, and the first digit identifies the general category of response:

o 1xx indicates an informational message only
o 2xx indicates success of some kind
o 3xx redirects the client to another URL
o 4xx indicates an error on the client’s part
o 5xx indicates an error on the server’s part The most common status codes are:
200 OK

The request succeeded, and the resulting resource (e.g. file or script output) is returned in the message body.
 
404 Not Found

The requested resource doesn’t exist.

301MovedPermanently 
302MovedTemporarily

The resource has moved to another URL (given by the Location: response header), and should be automatically retrieved by the client. This is often used by a CGI script to redirect the browser to an existing file.

500 Server Error

An unexpected server error. The most common cause is a server-side script that has bad syntax, fails, or otherwise can’t run correctly.

Header Lines

Header lines provide information about the request or response, or about the object sent in the message body.

The header lines are in the usual text header format, which is: one line per header, of the form “Header-Name: value”, ending with CRLF. It’s the same format used for email and news postings, defined in RFC 822, section 3. Details about RFC 822 header lines:

• As noted above, they should end in CRLF, but you should handle LF correctly.
• The header name is not case-sensitive (though the value may be).
• Any number of spaces or tab

Title:
Unit-5: Visual programming lecture notes (Advanced Concepts)

Subject:
Visual programming

Institute:
P.R.Engineering college

Unit-5: Visual programming lecture notes (Advanced Concepts)

Unit-5: Visual programming lecture notes (Advanced Concepts) in Visual programming uploaded at P.R.Engineering college

Summary / document preview text:

Modal

Are you sure to delete this information ?