Blocking(Synchronous) vs Non Blocking(Async) Sockets

In summary, there are three general approaches that can be taken when building an application with the control in regard to blocking or non-blocking sockets:
1) Use a blocking (synchronous) socket. In this mode, the program will not resume execution until the socket operation has completed. Blocking sockets in 16-bit application will allow it to be re-entered at a different point, and 32-bit applications will stop responding to user actions. This can lead to complex interactions (and difficult debugging) if there are multiple active controls in use by the application.
2)Use a non-blocking (asynchronous) socket, which allows your application to respond to events. For example, when the remote system writes data to the socket, a Read event is generated for the control. Your application can respond by reading the data from the socket, and perhaps send some data back, depending on the context of the data received.
3)Use a combination of blocking and non-blocking socket operations. The ability to switch between blocking and non-blocking modes "on the fly" provides a powerful and convenient way to perform socket operations. Note that the warning regarding blocking sockets also applies here.

If you decide to use non-blocking sockets in your application, it’s important to keep in mind that you must check the return value from every read and write operation, since it is possible that you may not be able to send or receive all of the specified data. Frequently, developers encounter problems when they write a program that assumes a given number of bytes can always be written to, or read from, the socket. In many cases, the program works as expected when developed and tested on a local area network, but fails unpredictably when the program is released to a user that has a slower network connection (such as a serial dial-up connection to the Internet). By always checking the return values of these operations, you insure that your program will work correctly, regardless of the speed or configuration of the network.

collision diameter

The CSMA/CD protocol does not allow a node to start transmitting while the wire is being used by another node (that is the carrier-sense part). However, it is possible for two nodes to start transmitting at almost the same time. The result is that the two transmissions interfere with each other and neither transmission can be properly received. The period during which a collision can occur is the time from when a node starts to transmit to when the signal actually arrives at all other nodes on the wire. This time depends on the physical distance between the furthest nodes on the wire. If this distance is too long, a node might finish transmitting a frame before it arrives at all nodes on the wire. This would make it possible for a collision to occur that the transmitting node would not detect. In order to prevent this from happening, the physical span of a shared-media Ethernet network is limited. This distance is known as the collision diameter; it is a function of the time necessary to transmit the shortest possible Ethernet frame (64 bytes). The collision diameter of a traditional Ethernet operating at 10Mbps is about two kilometers, which is plenty for most local area networks. However, the collision diameter shrinks at faster data rates, since the time it takes to transmit a frame is less. The collision diameter for Fast Ethernet, which operates at 100Mbps, is 200 meters—a limit that can be constraining in a large building. (The collision diameter for Gigabit Ethernet would be 20 meters, but because this distance is so ridiculously short, Gigabit Ethernet does not use CSMA/CD.)

Network Testing - Abstract Thinking

Creating a Network Test Plan

To prepare a plan to test the network. The plan defines the scope, approach, criteria, schedule, responsibilities, resources, and procedures.

Define Objectives

Define the objectives of the test by identifying the areas of the network to be tested including:

· Volume Testing. Ensures that the network operates smoothly when subjected to production volumes of data over long periods of time.

· Stress Testing. Ensures that the network operates smoothly when subjected to the maximum load expected in production, all at one time. A good rule of thumb is to subject the network to 25 percent more data and processing than is expected during peak loads.

· Recovery Testing. Ensures that backup and recovery procedures are working properly.

· Security Testing. Verifies that the network meets the security requirements.

· Performance Testing. Verifies that performance criteria are met (e.g., response times).

Define Acceptance Criteria

For each test objective, define the criteria for successful completion. For example:

· All expected results are achieved on the initial run.

· All severe, and high priority faults are corrected and the associated test(s) rerun successfully.

· A documented plan is put in place specifying how and when outstanding low and medium priority faults will be resolved.

Define Schedule

Identify the high-level activities and tasks together with expected start and completion dates.

Define Responsibilities

Identify the individuals who will be involved in the test and their roles and responsibilities.

Define Resources

Identify the staff, hardware, and software requirements. Confirm that the Network Deployment Plan has accounted for these requirements and resolve any differences.

Define Procedures

Define the procedures to be followed in preparing the test cases, preparing test scripts, preparing the test environment, conducting tests, and verifying test results.

Tips and Hints

Document any assumptions made while preparing the plan.

Plan to use automated test tools wherever possible to significantly reduce the testing effort and duration. Automated test tools can be used to generate and apply an adequate number of transactions to facilitate stress and performance testing.

PacketFactory Network Security Projects

• dnsa [DNS auditing tool]
• egressor [router config check]
• firewalk [gateway ACL scanner]
• hummingbird [asychronous scanning engine]
• ipgeo [IP geo-targeting lookup tool]
• ISIC [IP stack integrity checker]
• libexploit [generic exploit creation (overflows/format strings) library]
• libnet [network packet assembly/injection library]
• libnids [NIDS E-box library]
• libradiate [802.11b frame assembly/injection library]
• libsf [IP stack fingerprinting library]
• nemesis [command line IP stack]
• ngrep [GNU grep for the network]
• packit [tool to monitor, manipulate, and inject customized IPv4 traffic]
• sentinel [remote promiscuous mode detection tool]
• stephanie [OpeBSD hardening tool]
• zodiac [DNS protocol analyzer]