You only need a working knowledge of VB, as this example doesn’t attempt to make a complex program; we are aiming for something short (not much coding), simple and easy to follow.

Let’s begin. First, we should delve a bit into the architecture. The tool we are going to build comprises two parts: the server part, which would wait for connections to be made (just like a web server waits for users to connect), and the client part, which would initiate connections to the server (the way a browser initiates connection to a web server).

To store the respective parts of our project, create two subfolders in the folder where you are going to save your project. Name the first one “Client” and other one “Served.

The Server:
Open Visual Basic 6 and Select “Standard Exe” for our new project in the dialog box that appears. Once the interface is displayed with a form visible in the center, go to File > Save Project. This will ask you to provide a name for your form. We are going to code the server first, so select the Server folder just created. Name your form frmServer. Next, another dialog box will ask you to save your project. Name it prjServer. Once this is done, you should make it your habit to press CTRL+S while you code, to make sure your code is not lost in case the application hangs or some other catastrophe occurs.

Now let’s change the default text, ‘Form1′, that appears in the title bar. To do this, we are going to edit the ‘Caption’ property of the form. Properties can be accessed through the Properties box displayed at the bottom right of VB interface. This is a two-column, table-like box, where the first column displays a property’s name and the corresponding cell in the second column displays its setting or value. Whatever item is selected on the form, its properties are listed in properties box, from where you can edit them. Your form is selected by default (indicated by the resize handles on its boundaries) and the properties box has the ‘Caption’ properly highlighted. Write ‘Server’ in place of ‘Form1′.

Now, add two text boxes and a command button to the form (by first selecting the text box icon from the toolbar on the left-hand side of the VB interface, and drawing it on the form according to the size you desire; you can also simply-double-click a control icon on the toolbox to have it placed over the form). The two text boxes are for chat purposes, while the command button is required to initiate the operation of sending text to the client. Set the ‘Name’ property of the first text box to ‘txtChatln’, of the second text box to ‘txtChatOut’ and lastly, name the command button ‘cmdSend’ and set its caption property to ‘Send’ (default was ‘Command1′). These names are for our own convenience and could be anything
From the ‘Text’ property of the two text boxes, remove ‘Text1′ & ‘Text2′ respectively (the default texts) and leave the fields blank. The second text box (txtChatln), which you should resize, is used for handling incoming chat text, and so should have the extra feature of being able to scroll as new text arrives. To add this functionality, set txtChatln’s ‘MultiLine’ property to ‘True’ and the ‘ScrollBar’ property to ‘2–Vertical’. This is available as the second choice in the drop-down list that appears when you attempt to change ‘ScrollBar’ property.

Now it’s time to add socket control–the brains of our application. This control is not listed in the default list that appears in the toolbox; you will have to bring it there. Here’s how: Right-click on the toolbox, and select ‘Components’. A component list dialog box is displayed. Scroll down and check ‘Microsoft Winsock Control 6.0′, and press OK. You will see that a new control with an icon showing two PCs has now been added to the toolbox. Using this, place a socket on your form and name it ’sckServer’. On the form it would look as though it is the same icon as in the toolbox.

When you press F5 to test run the project, you will observe that socket control is not visible–this is normal, as this control is invisible at run-time. Users do not have to interact with sockets like the text box and command buttons. We give commands to sockets using only codes.

Time to add code: infusing blood into this body! Double- click the form (make sure it’s not a control but the form on which you are clicking). The coding pane has got two dropdown lists on the top. As you have double-clicked the form, you will see ‘Form’ in the first dropdown (on left) and ‘Load’ in the other dropdown (on right). The first shows the item and the second shows the event associated with that item. This means that you are now coding for the form’s Load event. An event is something that happens with an item (the form is loaded when the application starts, so Load is an event of the form). Whenever you will double-click a form or control, you will enter its coding window; see its name in the first dropdown and the event for which code is being entered in the second dropdown.

Add the following code in the form’s load event.
sckServer.LocalPort = 6000
sckServer.Listen
This will make the server listen (wait for connections) on port 6000 as soon as the application starts.

Now that you are in the coding window, if you want to go back to your form design window, simply double-click Form1 in the project explorer box on the right-hand side of the VB interface. You can also use menu ‘Windows > Form1 (Form)’.

Similarly, add the following code to the command button which we have named cmdSend. Do this by double-clicking the button when you are in the form design window. Note that the event listed in the second dropdown is ‘Click’ which signifies that when this code will be executed, the button’s event will be a click.

sckServer.SendData txtChatOut.Text
& vbCrLf
txtChatOut.Text=”"

The first line tells the socket (sckServer) to send the data present in the text box (txtChatOut) along with a new line character, so that every line of text starts with a new line on the other side (i.e. the client, which we will be coding after we are done with the server). The second line empties the text box we are using in anticipation of the next text a user might type.

Now double-click the socket control we have placed on form to add code in its ‘ConnectionRequest’ event (Fig 3b). Note that this event is not selected by default when you enter the coding window. Select this event from the second dropdown (on the right), which lists all the possible events for our socket (sckServer).

If sckServer. State <> sckClosed Then
sckServer. Close
sckServer. Accept requestlD

This is the way to accept connections when a connection request arrives at the socket. Note that we are coding a server (as we have instructed the socket to listen), and that’s why we have to tell sockets how to accept connections when requests come from clients. It’s not a problem if you don’t understand what these two lines do at the moment, as this code has nothing to do with the functionality aspects of our program and is only used to accept connections. (For inquisitive readers, in short, the first line checks the socket state and the second line invokes an accept method with the Request ID returned by an incoming connection request).

Now select ‘DataArrival’ event from the second dropdown on the top, which currently displays ConnectionRequest. Add the following code.

Dim ChatData As String
sckServer.GetData ChatData
txtChatln.Text = txtChatln.Text & ChatData

The variable “ChatData” of type “String” is declared (first line) and used with the “GetData” method of the socket to get incoming data (second line). Finally, the third line updates the incoming chat text box with new data. The reason for assigning txtChatln & ChatData to txtChatln is to make sure that the current contents are net overwritten by the new data arrival.

The Client
Open another VB 6 file and select ‘Standard Exe’ for the new project. Once the interface is displayed, with a form visible in the center, save the form and project in the folder Client (already created) with names frmClient and prjClient respectively.

Set the ‘Caption’ property of this form to ‘Client’. In exactly the same way as for the server part, add a Winsock control to this form (right-click toolbox, select ‘Components’, select ‘Microsoft Winsock 6.0′). Name it ’sckClient’.

Add two text boxes and a command button. Name the text boxes ‘txtChatln’ and ‘txtChatOut’. Set txtChatln’s ‘MultiLine’ property to ‘True’ and ‘ScrollBar’ property to ‘2–Vertical’. This is available as the second choice in the dropdown tist that appears when you attempt to change the ‘ScrollBar’ properties. Remove ‘Text1′ and ‘Text2′ from ‘Text’ properties of both text boxes and leave these fields blank. For the command button, set the ‘Name’ property to ‘cmdSend’, and its ‘Caption’ property set to ‘Send’. After resizing the form and positioning controls over it, let’s do the coding part. For the form’s lead event, add the following code:

sckClient.RemoteHost = “localhost”
sckClient.RemotePort = 6000
sckClient.Connect

For communications, we need two pieces of information: the address of the remote machine and its port number. For a remote host, we have specified a local host–this is your own PC, because at this time, the server is also running on the same PC. As we have already set our server to listen on port 6000, the same is specified over here as well. As we are building and running this application on the same PC, we have used Iocalhost (you can also enter 127.0.0.1 in place of Iocalhost, along with the inverted commas as seen in line 1), but in case you are using this chat program to communicate over a network, you need to specify the IP address of the machine on which you have set your server to listen, instead of Iocalhost. The last line instructs our socket to connect to the server.

Now add the code for the send button. This works exactly the same way as the send button of the server.

sckClient.SendData txtChatOut.Text&
vbCrLf
txtChatOut.Text = “”

Starting Chat
Go to your server project and press F5 to run it. Your server is in listening mode now. Recall that we had placed listen code in Ioad event of server form. Come back to the client project and press F5 to run it too. Client will make connection with the server as we have just added connection code in Ioad event of client form. At this time we have not added any visual indication that a connection has been established or what the status of the connection is, we need to test it by typing some text in either the client or the server, in the text box just above the send button (this is the txtChatOut text box on both forms). This text would appear on the other part’s bigger text box with scrollbar (the txtChatln text box on both forms).

You can go to ‘File > Make you project.exe’ menu to create standalone executable files for both client and server.

Remember while you testing to run the server first and then the client (otherwise the client will attempt to connect to a non-existent server!) and if you happen to close either part, close the other one too and start afresh.

This is a very basic chat application with minimal features and as
little code as possible.

+ If you create a new user account and then use System Restore to roll back your system configuration to a point before the new account was created, the new user will no longer be able to log on, and you will receive no warning. (The good news is that the new user’s documents will be intact.)

+ System Restore does not uninstall programs, although it does remove executable files and DLLs. To avoid having orphaned program shortcuts and files, make a note of any programs that you installed after the date of the restore point you’re about to roll back to. If you don’t want the program anymore, uninstall it in the normal way before running the restore operation. If you want to continue using the program, reinstall it after the restore is complete.

+ Any changes made to your system configuration using the Windows Recovery Environment are not monitored by System Protection. This can produce unintended consequences if you make major changes to system files and then roll back your system configuration with System Restore.

+ Although you can restore your system to a previous configuration from Safe Mode, you cannot create a new restore point in Safe Mode. As a result, you cannot undo a restore operation that you perform in Safe Mode. If possible, you should always start Windows normally to perform a restore operation.

Unfortunately, performance problems are messier. Here are just a few of the reasons that network administrators hate performance problems:

Performance problems are difficult to quantify. Exactly how much slower is the network now than it was a week ago, a month ago, or even a year ago? Sometimes the network just feels slow, but you can’t quite define exactly how slow it really is.

Performance problems usually develop gradually. Sometimes a network slows down suddenly and drastically. More often, though, the network gradually gets slower, a little bit at a time, until one day the users notice that the network is slow.

Performance problems often go unreported. They gripe about the problem to each other around the water cooler, but they don’t formally contact you to let you know that their network seems 20 percent slower than usual. As long as they can still access the network, they just assume that the problem is temporary, or that it’s just their imaginations.

Many performance problems are intermittent. Sometimes a user calls you and complains that a certain network operation has become slower than molasses, and by the time you get to the user’s desk, the operation performs like a snap. Sometimes you can find a pattern to the intermittent behavior — say, it’s slower in the morning than in the afternoon, or it’s slow only while backups are running or while the printer is working. Other times, you can’t find a pattern. Sometimes, the operation is slow; sometimes, it isn’t.

Performance tuning is not an exact science. Improving performance sometimes involves educated guesswork. Will segmenting the network improve performance? Maybe. Will adding another 512 MB of RAM to the server improve performance? Well, hope springs eternal.

Thee solution to performance problems is sometimes a hard sell. If a user is unable to access the network due to a malfunctioning component, there’s usually not much question that the purchase of a replacement is justified. However, if the network is slow and you think you can fix it by offloading your server’s contents onto a separate server, you may have trouble selling management on the new purchase.
 
 
—————————————
BCBG Shoes
KEEN Shoes
 
 

After the initial connection request, the client would need to hear an RSN IE broadcast or send a probe request with an RSN IE. Whichever way this RSN IE frame is sent, both clients and access points need to negotiate on a cipher suite for use. After sending the RSN IE frames and reaching a negotiation, the EAP process starts. This can start with the access point sending an EAP identity request or a client sending an EAPOLStart frame. Once the EAP process has started, it will go through the EAP authentication process associated with each particular EAP type. It ends with the client receiving an EAP success message from the access point. During this process, an AAA key is sent from the authentication server to the wireless end device. This key is used as a seed key to create the keys outlined below.

The key exchange process takes the original 802.1x EAPOL-Key frame and makes some modifications, allowing for the use of WEP-40, WEP- 104, TKIP, and CCMP cipher suites. The EAPOLKey frame only supports WEP-40 and WEP-104 keys. The 802.11i standard modified this and added the ability for the frame to carry TKIP and CCMP keys as well. A process known as the four-way handshake accomplishes this key exchange. This process takes two main keys and creates unique group and session keys for each client. These session and group keys are created from the two main keys: (1) the pairwise key or the pairwise master key (PMK) and (2) the group key or the group master key (GMK).

In an 802.1x 802.11i setup, the PMK comes from the authentication server. If the 802.11i setup is using preshared keys, then the PMK is mapped to a password. The PMK is divided into three keys. The first key is the EAPOL-key confirmation key (KCK), which is used to provide data origin authenticity. The second key created from the PMK is the EAPOLkey encryption key (KEK), which is used to provide confidentiality. The last key is called the pairwise temporal key (PTK) and this key is also used for data confidentiality. To create the PTK, a pseudorandom function takes place with the access point’s MAC address, client MAC address, and a nonce sent from each side as well. This allows a single master key to create multiple session keys without having to re-exchange a new master key each time.

The next key with regard to 802.11i main keys is the group key or group master key (GMK). This key is similar to the PMK except that it is used for beacon and management traffic encryption. The same process of hashing senders’ and receivers’ MAC addresses and nonces is used to create a group temporal key (GTK) from a group master key. Having discussed the keys and how they are split up to accommodate session encryption, one can now look more closely at the four-way handshake. This handshake starts with the authenticator sending the supplicant a nonce. This is often referred to as the ANonce in the 802.11i standard. This nonce is a random value used to prevent replay attacks. This means that old nonces cannot be reused. After each party receives a message, the first step before any other is to check and see if the nonce was changed or if the same nonce was incorrectly reused. Once the wireless client receives the first message, it will check the nonce and then generate an SNonce. This nonce will be used in the next step to calculate the pair transient key (PTK). After the PTK is created, the client will then send the SNonce as well as the security parameters outlined in the RSN IE frame to the access point. This information is the second message in the four-way handshake. All of this information will be encrypted using the KCK, which will protect it from any modification while in transit. Once the access point receives this, it will check that the nonce is not an old value. Once this is done, it will also generate the PTK from the SNonce and ANonce, and then check the KCK to make sure it was not modified in transit. Once this is done, the third message in the four-way handshake will take place. This message is used to tell the client to install the PTK key that was created and, if used, this message will send a GTK to the client to install. Once the client receives this, it will check the KCK and, if it is correct, install the key or keys. The last message is a confirmation used to let the authenticator know that the client has successfully installed the keys and is ready to communicate using them.

TKIP was included in the 802.11i standards for backwards compatibility. The 802.11i standard did not want to use a cipher based RC4, so they chose AES. TKIP was put into 802.11i for the sole reason of helping older devices transition to 802.11i. To do this, 802.11i needed to support a protocol that could easily upgrade WEP to something safe enough to include in 802.11i. One of the main reasons for using TKIP over WEP came from the increased security and increasing number of attacks that were plaguing the WEP protocol. Using TKIP protected against these attacks and reduced the overall risk of operating a wireless network.

The TKIP standard also saw value in the industry because the migration from WEP to TKIP was an easy one. In most cases, moving from WEP to TKIP involved a small firmware change. This meant that no hardware was required to make the change and also that most older, already purchased equipment would be able to upgrade to TKIP.

Another interesting note about TKIP comes from Cisco Systems. Cisco came up with a TKIP solution well before the 802.11i standard defined one. This has led some people to wonder about which version of TKIP is on a certain product. Vendors other than Cisco also created TKIP-based solutions before the standard was ratified. Today, Cisco differentiates its versions of TKIP and the standard one by calling it the Cisco Key Integrity Protocol (CKIP). In Cisco products, one can specify to use TKIP, which is the 802.11i-compliant version, or CKIP, which is the Cisco-created version.

The TKIP encryption portion works in a two-phase process. The first phase generates a session key from a temporal key, TKIP sequence counter (TSC), and the transmitter’s MAC address. The temporal key is made up of a 128-bit value similar to the base WEP key value. The TKIP sequence counter (TSC) is made up of the source address (SA), destination address (DA), priority, and the payload or data. Once this phase is completed, a value called the TKIP-mixed transmit address and key (TTAK) is created. This value is used as a session-based WEP key in the second phase.

In the second phase, the TTAK and the IV are used to produce a key that encrypts the data. This is similar to how WEP is processed. In WEP the first 24 bits of the IV are added in front of the WEP key and then used to create an encryption key that is applied to the data. Then the IV is inserted into the packet header. TKIP extended the IV space, allowing for an extended IV field, which holds an additional 24 bits. In the second phase, the first 24 bits are filled with the first 24 bits of the TTAK. The next 24 bits are filled with the unused portion of the TSC. This is safer than WEP because the key is using a different value, depending on who one is talking to. In WEP, each client or access point creates the same random value. Some products never even created a random value and just incremented the value by one, making it an easy target for hackers.

The basis of TKIP came from the WEP protocol. In the 802.11i standard, TKIP is referred to as a cipher suite enhancing the WEP protocol on pre- RSNA hardware. This is espoused because RC4 is still used as a cipher, although the technique in which it is used has improved greatly.

TKIP Message Integrity Check (MIC)

Similar to TKIP, the Message Integrity Check (MIC) had also many versions before 802.11i defined it as a single standard. Once this was done, MIC became known as Michael although the acronym MIC still remains. Today with 802.11i, ratified MIC is Michael and vice versa. The protocol itself was created to help fight against the many message modification attacks that were prevalent in the WEP protocol. The IEEE 802.11i standard describes the need for MIC in the following quote: “Flaws in the IEEE 802.11 WEP design cause it to fail to meet its goal of protecting data traffic content from casual eavesdroppers. Among the most significant WEP flaws is the lack of a mechanism to defeat message forgeries and other active attacks. To defend against active attacks, TKIP includes a MIC, named Michael.” The MIC was created as a more secure method of handling integrity checking compared to the IVC in WEP.

The MIC is a hash that is calculated on a per-packet basis. This means a single MIC hash could span multiple frames and handle fragmentation. The MIC is also on a per-sender, per-receiver basis. This means that any given conversation has a MIC flowing from sender A to receiver B and a separate MIC flowing from sender B to receiver A.

The MIC is based on seed value, destination MAC, source MAC, priority, and payload. Unlike IC, MIC uses a hashing algorithm to stamp the packet, giving an attacker a much smaller chance to modify a packet and have it still pass the MIC. The seed value is similar to the WEP protocol’s IV. TKIP and MIC use the same IV space, although they have added an additional four octets to it. This was done to make the threat of using the same IV twice in a short time period less likely.

The MIC is also encrypted inside the data portion, which means it is not obtainable through a hacker’s wireless sniffer. To add to this, the TKIP also left the WEP IVC process, which then adds a second, less secure method of integrity checking on the entire frame. To combat message modification attacks, the TKIP and MIC went a step further and introduced the TKIP countermeasures procedures. This is a mechanism designed to protect against modification attacks. It works by having an access point shut down its communications if two MIC failures occur in 60 seconds. In this event, the access point would shut down for 60 seconds. When it comes back up, it would require that all clients trying to reconnect change their keys and undergo a re-keying. Some vendors allow one to define these thresholds, although the MIC standard calls out these values.

To prevent noise from triggering a TKIP countermeasure procedure, the MIC validation process is performed after a number of other validations. The validations performed before the MIC countermeasure validation are the frame check sum (FCS), integrity check sum (ICV), and TKIP sequence counter (TSC). If noise was to interfere with the packet and modify it, one of these other checks would be able to find it first, thus preventing the frame from incrementing the MIC countermeasure counter.

Compared to previous Windows versions, the number of available options is extremely limited. The Windows Features dialog box, indicates which features are available for your edition. A check mark means the feature is currently enabled, and a blank box means the feature is disabled. If you see a filled box, the feature is partially enabled; click the plus sign to the left of the entry to see more details about it.

In fact, these items are not folders at all; they are junctions or symbolic links that point to their Windows Vista corollary folders. (For example, the Documents And Settings folder is merely a pointer to the Users folder.) These junction points are in place to provide compatibility for older applications for Windows. As part of their implementation, the Everyone group has a Deny ACE for List Folder / Read Data.

The solution is simple: do not use these folders for navigation! Aside from application compatibility, they offer nothing that the new folder names do not. Don’t delete the folders, and don’t remove the Deny permission, as that can have other unintended consequences. To work on the files and folders that appear to be in these folders, instead follow the path of nonhidden folders to find the same files and subfolders. Honestly, the best solution is to hide the protected operating system files, and forget that you ever found these folders.

The command to export cookies was included in Internet Explorer to provide users with a way to transfer their cookies to the format used by Netscape browsers. But it works just as well as a backup tool. If you ever need to restore your cookies, run the Import/ Export Wizard again, and point the wizard to the file you exported earlier.

Unfortunately, many of the Windows-tuning tips we’ve seen are of dubious value, and a few can actually hurt performance when indiscriminately applied. Some of these spurious tips are derived from techniques that worked with older Windows versions but are irrelevant now. Others are based on seemingly logical but erroneous extrapolations of how would-be experts think Windows works.

Page File Confusion

By far the most common instances of performance-related misinformation revolve around the subject of page files, also known as swap files. The following are some widely published myths about the proper configuration of virtual memory in Windows:

If your computer has a large amount of memory installed, you should eliminate your page file completely. This is incorrect. Although you can configure Windows so that it does not set aside any virtual memory, no reputable source has ever published benchmarks establishing any performance gains from doing so, and Windows simply wasn’t designed to run without a page file. If the goal is to conserve disk space, a more sensible strategy is to configure Windows to create a page file with a relatively small minimum size and monitor its usage over time to see how much virtual memory the operating system actually uses in daily operation.

Creating a page file of a fixed size improves performance. This is also bad advice. The logic behind this tip dates back to the earliest days of Windows. On 1990s-vintage hardware, dynamically resizing the swap file caused noticeable delays in system response and also resulted in excessive fragmentation. The memory management subsystems in Windows XP and Windows Vista have been tuned to minimize the likelihood of performance problems.

Prefetch Pros and Cons

To improve the speed of starting applications, Windows continually monitors files that are used when the computer starts and when you start applications. It then creates an index (in the %SystemRoot%\Prefetch folder) that lists segments of frequently used programs and the order they’re loaded in. This prefetching process improves performance by allowing the operating system to quickly grab program files.

A widely circulated tip of dubious value recommends that Windows users clean out the Prefetch folder and consider disabling the Prefetch function. Some sites even provide links to utilities that automate these functions.

Clearing out the Prefetch folder forces Windows to run programs inefficiently—but only once, since Windows rebuilds the Prefetch layout for a program the next time you run that program. Disabling the Prefetch function eliminates Windows’ ability to optimize program loading. In either case, it’s hard to find a logical reason why the tweak should result in a performance improvement.

Is it necessary to clear out the Prefetch cache occasionally to eliminate obsolete files and to minimize wasted disk space, as some websites claim? Hardly. A typical Prefetch folder uses 3-6 MB of disk space, and Windows flushes entries that are older than a few weeks. Our take? The developers responsible for the memory management subsystem of Windows did a remarkable job when they devised this feature. Don’t turn it off.

Shutting Down Services

We’ve also seen sites focusing on Windows services. One sensible piece of advice is to minimize the use of unnecessary background applications and system services. A few sites take this advice to an extreme, however, urging Windows users to shut down virtually all system services, including System Restore and Automatic Updates. We don’t agree that the average Windows user should perform this sort of radical surgery on Windows. In less-than-expert hands, the Services console is a minefield; some Windows services can be safely disabled, but indiscriminately shutting down services is a prescription for trouble.