Fragmentation in TSL

The record layer fragments information blocks into TLSPlaintext
records carrying data in chunks of 2^14 bytes or less.Client
message boundaries are not preserved in the record layer (i.e.,
multiple client messages of the same ContentType MAY be coalesced
into a single TLSPlaintext record, or a single message MAY be
fragmented across several records).

struct {
uint8 major;
uint8 minor;
} ProtocolVersion;

enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255)
} ContentType;

struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;

type
The higher-level protocol used to process the enclosed fragment.

version
The version of the protocol being employed.This document
describes TLS Version 1.2, which uses the version { 3, 3 }.The
version value 3.3 is historical, deriving from the use of {3, 1}
for TLS 1.0.(See Appendix A.1.)Note that a client that
supports multiple versions of TLS may not know what version will
be employed before it receives the ServerHello.See Appendix E
for discussion about what record layer version number should be
employed for ClientHello.

length
The length (in bytes) of the following TLSPlaintext.fragment.The
length MUST NOT exceed 2^14.

fragment
The application data.This data is transparent and treated as an
independent block to be dealt with by the higher-level protocol
specified by the type field.

Implementations MUST NOT send zero-length fragments of Handshake,
Alert, or ChangeCipherSpec content types.Zero-length fragments of
Application data MAY be sent as they are potentially useful as a
traffic analysis countermeasure.

Note: Data of different TLS record layer content types MAY be
interleaved.Application data is generally of lower precedence for
transmission than other content types.However, records MUST be
delivered to the network in the same order as they are protected by
the record layer.Recipients MUST receive and process interleaved
application layer traffic during handshakes subsequent to the first
one on a connection.

Querying and Updating the WMI Repository

You can use Windows Management Instrumentation (WMI) to view and update a running application's configuration data when you use the Manageable Configuration Source to expose your Enterprise Library configuration. The Manageable Configuration Source reads information from the configuration file, applies any applicable Group Policy overrides, and exposes the configuration information to applications as a series of configuration class instances in the same way as the other Enterprise Library configuration sources.

However, the Manageable Configuration Source also exposes the configuration information through the .NET WMI 2.0 API and to the WMI Repository as a set of WMI classes that you can query and view. This allows administrators and users to examine configuration information using standard Windows-based management tools or code.

In addition, administrators and users can update the values of the WMI objects using standard Windows-based management tools or code. These changes update the configuration information exposed to the application by the Manageable Configuration Source, which also raises a ConfigurationChanged event that allows the application to react to the changes and reload the new configuration values.

Note:
You must have the relevant Windows permissions to update WMI objects. In addition, as changes pass back to the Manageable Configuration Source, it reapplies any relevant Group Policy overrides. If the change conflicts with a Group Policy setting, the Manageable Configuration Source will ignore the change and continue to expose the Group Policy-applied value.

Changes you make to the configuration exposed by the WMI objects are exposed by the Manageable Configuration Source and are visible in the application. However, they do not change the contents of the original configuration file. When the application restarts, or if you make changes to the configuration file contents, any updates made through WMI are lost. 

The following table lists the ways you can query and update values in the WMI Repository.

Adding a Manageable Configuration Source

If you want to use Group Policy or Windows Management Instrumentation (WMI) with an application, you must first add a manageable configuration source. Although the procedures shown here use the Configuration Console, you can use the same procedures with the Configuration Editor that is integrated with Visual Studio. For more information about the Configuration Editor, see Using the Configuration Tools.

To add a manageable configuration source

Start the Enterprise Library Configuration Console or the Visual Studio Configuration Editor. To use the Configuration Console, click Start, point to All Programs, point to Microsoft patterns & practices, point to Enterprise Library 4.1 – October 2008, and then click Enterprise Library Configuration.
Click New Application or Open Existing Application.
Right-click the application configuration file listed under Enterprise Library Configuration, point to New, and then click Configuration Sources.
Right-click the Configuration Sources node, point to New, and then click Manageable Configuration Source.
Click the Configuration Sources node.
In the right pane, click SelectedSource.
In the drop-down list, click Manageable Configuration Source.
Click the Manageable Configuration Source node. In the right pane, set the configuration settings. By default, both WMI and Group Policy are enabled. You must provide an entry for the File property.
Right-click the System Configuration Source, and then click Remove.
On the File menu, click Save Application.

Changes to the Policy Injection Application Block

The following changes have been made to this version of the Policy Injection Application Block:

• Fixed : Design time for the policy injector collection now reads the default injector from the configuration file. The node creation classes are updated to set the default injector node property on the injectors collection node.
• Changed : The matching classes implementation has changed. The implementation was moved to Unity. The classes still exist in the Policy Injection Application Block as configuration placeholders to provide backward compatibility.
• Changed : The Policy Injection Application Block can now use a container. The container is configured with the Policy Injection Application Block configuration.
• Changed : The Policy Injection Application Block now has only the default interceptor. Non-default interceptor options have been removed. The <injectors> element has been removed. The default interception mechanism of the Policy Injection Application Block enables you to reuse existing object instances.
• Changed Remoting Interception has been renamed Transparent Proxy Interception.