With ASP.NET AJAX you can:
Create next-generation interfaces with reusable AJAX components.
Enhance existing pages using powerful AJAX controls with support for all modern browsers.
Access remote services and data from the browser without tons of complicated script.
Take advantage of the improved efficiency and ease of use in Visual Studio 2008, with its built-in support for ASP.NET AJAX, improved JavaScript support, and a new Web page designer interface.
A Quick link to the video demonstrating the basics of AJAX
http://www.asp.net/learn/3.5-videos/video-362.aspx
Thursday, April 23, 2009
Friday, March 7, 2008
web ip spofing
An IP spoofing attack is one in which the source IP address of a packet is forged. There are generally two types of spoofing attacks: IP spoofing used in DoS attacks and man in the middle attacks.
IP spoofing-based DoS attacks are relatively straightforward. An attacker sends a packet to the target host with a forged IP address (SYN)—often an IP address in the RFC 1918 address space, though it does not have to be. The targeted host sends an acknowledgement (ACK) and waits for a response. The response never comes, and these unanswered queries remain in the buffer of the targeted device. If enough spoofed queries are sent, the buffer will overflow and the network device will become unstable and crash.
Man in the middle attacks are much more onerous. Here, the attacker intercepts traffic heading between two devices on the network. The attacker can either monitor information or alter the data as it passes through the network. This is illustrated in Figure 3.5.
Figure 3.5 The user sends a request to 10.10.100.1. The attacker pretends to be 10.10.100.1 and sends a response to that effect. The user then forwards all packets destined for 10.10.100.1 to the attacker.
Typically a man in the middle attack works like this: An attacker sits on the network and watches traffic. When another user on the network sends an ARP request to a network device, the attacker sends a response saying the compromised machine is the requested device. Even if the actual device responds, the second response will override the first. The user now sends all data destined for the original device to the compromised machine.
It is possible for an attacker to use this method to intercept enough data to effectively monitor and log all network traffic and gain important information such as usernames and passwords. Users may never know that the traffic is being intercepted, because each packet will eventually be forwarded onto its intended destination.
IP spoofing-based DoS attacks are relatively straightforward. An attacker sends a packet to the target host with a forged IP address (SYN)—often an IP address in the RFC 1918 address space, though it does not have to be. The targeted host sends an acknowledgement (ACK) and waits for a response. The response never comes, and these unanswered queries remain in the buffer of the targeted device. If enough spoofed queries are sent, the buffer will overflow and the network device will become unstable and crash.
Man in the middle attacks are much more onerous. Here, the attacker intercepts traffic heading between two devices on the network. The attacker can either monitor information or alter the data as it passes through the network. This is illustrated in Figure 3.5.
Figure 3.5 The user sends a request to 10.10.100.1. The attacker pretends to be 10.10.100.1 and sends a response to that effect. The user then forwards all packets destined for 10.10.100.1 to the attacker.
Typically a man in the middle attack works like this: An attacker sits on the network and watches traffic. When another user on the network sends an ARP request to a network device, the attacker sends a response saying the compromised machine is the requested device. Even if the actual device responds, the second response will override the first. The user now sends all data destined for the original device to the compromised machine.
It is possible for an attacker to use this method to intercept enough data to effectively monitor and log all network traffic and gain important information such as usernames and passwords. Users may never know that the traffic is being intercepted, because each packet will eventually be forwarded onto its intended destination.
Tuesday, February 26, 2008
linux file system structure
Linux File System Structure The Linux system contains thousand of files located within many directories. All directories are organized in a tree-structure like manner.
The 'trunk' of the tree is the root directory. The root directory is simply identified as a "/". All other directories 'branch' off from the trunk. The following lists the most common directories and their intended contents.
/ - root directory
/home - where directories are contained for each user, example: /usr - pronounced 'user' and contains Linux commands and utilities
/bin - binary executable programs
/lib - program libraries, similar to Windows 'dll' files
/sbin - more executable programs and Linux utilities for administrative purposes
/doc - documentation
/src - source code to programs
/tmp - temporary work files /etc - configuration files
/rc.d - scripts used during boot and shutdown process
/sysconfig - default configuration files
/sysconfig/network-scripts - network scripts
/sysconfig
/daemons - special programs that run in background, such as print spooling
/bin - binary executable programs that all users need
/dev - device files that control drives, terminals and any equipment attached to the server
/var - user specific files
/log - log files containing system usage and errors
/spool - where spooled files are stored during print spooling process
/mail - where Email files are stored until retrieved by client Email program
/proc - system files
/root - root's home directory
/opt - other options
/sbin - more executable programs and utilities
database vs file base system
. In general, file-based servers perform better when update operations are very large or instances are relatively small, while databases are best when small updates are frequently performed against large instances. 2. Files tend to be much faster to read than databases. The startup time depends primarily on the time it takes to read the server�s instances, so using a database backend may more than double startup times. 3. When creating, copying, or modifying a repository instance the entire instance needs to be written, so file-based instances tend to be faster. Deleting instances is especially faster for file-based instances because it involves a single operating system operation, file delete, as opposed to the query and deletion of all appropriate rows in the database. 4. When using the repository server�s fault tolerant feature, multiple servers are run all serving the same data. Common data can be shared either by using a common persistent store such as a shared database or network mounted files, or by replicating the persistent store. For databases, it is very easy for all servers to share a common database. For files, using a network mounted file introduces a single point of failure. Replicating file instances so each server has a local instance on its system provides for a complete fault tolerant solution with each system able to run independently. However, replicating files introduces an additional process that can break down leading to inconsistencies in the data being served. 5. Files have no cost other than the IT overhead of supporting a backup process. Databases on the other hand can be expensive if you do not have a site-license with one of the supported database vendors. In summary, the choice of file versus database will depend on your particular situation. Performance is an important factor, but it is not the only one, because so much of performance is not related to the backend storage choice. Reliability and cost should also be considered when selecting the appropriate solution.
Subscribe to:
Posts (Atom)
