So as to avoid having to answer questions about it in email for a while...

TCPClient is undergoing a major "hardcore" upgrade. It will, it seems, be a few months before there is sufficient free time to produce a version for public release.

Among the changes are:

UNICODE
New version of SendRN, etc that handle 8, 16 and 32-bit UTF unicode. You can handle unicode right now, but only if you treat it as binary data. Which is slightly cumbersome.


CRYPTOGRAPHIC SUPPORT
Full support for SSL v1/v2/v3 and TLS v1 including several public-source hashing functions (MD5, etc) and (psuedo)random-number generation algorithms. Uses both weak and strong cryptography. (For US export and pesky support reasons there is a possibility that the version using "strong" encryption may be commerical. Perhaps.)

This basically mean you can open secure connections to anything else using SSL or TLS such as HTTPS.

The amount of coding involved is also what is holding up the release of 3.x.


S/MIME
To handle the sending and receiving of encrypted email, additional semi-automatic MIME handling functions have been added. This also makes sending of non-encrypted mail attachments much, much less of a hassle.


"FRAMING"
Several protocols, mostly those that "stream" data, send their information in data frames. That is, their data is arranged in logical units that resemble data structures from "c" (called STRUCT's).

The framing functions allow you to set-up your data (numbers, strings, n-bit binary data, etc) using sets of pseudo-code to define their organization. It allow allows the setting up of "key" variables which determine which frame organization is being used.

Basically, another way to think of this is a set of templates, or cards on a binder ring. On the card's you've written out the name of each field and what it is. Somewhere on the card you punch out a "key". When the key on a card matching the actual data being recieved/send then that card is used.

For a simple example, say you're talkin to a bank and it's sending back frames that are always 256 bytes in size consisting of a field "Type" (which is numeric byte) and one other field called "String" which is a space-padded ASCII string.

The "type" field might either be "1", indicating the "string" is the customer's name or "2" indicating it's their full billing address.

The frame functions would automagically present you with the correct frame/template depending on the key.

Most banking protocols are much more complicated than this, but I can't talk about that. :-) You get the idea hope however.

--min