Proxies and firewalls are a complex subject, and the answer
greatly depends on your particular setup. HexGadgets do not
include any proxy-related provisions themselves.

HexDns and HexLookup: You may have a DNS
server on your local network that they can use. Queries can
go through a firewall if it allows outgoing UDP traffic to
port 53.

HexValidEmail: DNS validation uses HexDns, so the
statements above apply. For SMTP validations, you will
probably need either a direct path to the Internet or SOCKS
redirection software such as NEC's
SocksCap. Firewalls will need to allow outgoing traffic
to TCP port 25 (for SMTP).

HexTcpQuery: For Whois and most other protocols, you will
probably need a direct path to the Internet or a SOCKS
redirector. For HTTP, however, you can probably use
the simple CERN proxy protocol:

To get our home page, you would normally connect to our
server on port 80 and send the following query:GET / HTTP/1.0

To use a CERN proxy, you would connect to your proxy
server on the appropriate port and send this query:
GET http://www.hexillion.com/ HTTP/1.0

With CERN proxying, you use the normal HTTP protocol
but connect to the proxy server and specify a full URL.
Furthermore, because you're specifying a URL, you may able
access other protocols such as FTP through this mechanism.
For example:GET ftp://ftp.microsoft.com/ HTTP/1.0

HexIcmp: You will need direct ICMP access to the Internet
or some other provision.

Yes and no. The current HexGadgets only operate synchronously.
In other words, the executing thread cannot continue until a
method call has returned. Thus, HexGadgets will only be able to
do one thing at a time in a single thread (such as that of an
ASP request). If your programming system allows multiple
threads, however, you can simultaneously run a HexGadget
operation in each thread.

Yes, but you will not be able to use runtime keys for the
HexGadgets in these environments because MTS/COM+ packages do
not support the IClassFactory2 licensing interface. Also,
HexValidEmail will not be able to use its runtime license for
HexDns, so you will need a separate license for HexDns in this
case.

In short, HexGadgets use numeric IP addresses because it's a cleaner
design. Specifically, it

Isolates different areas of functionality into different components, providing better
encapsulation and granularity. For example, you can have separate Timeout and Error
properties for lookups, TCP queries, ICMP communications, and so on, instead of having
them all lumped together.

Avoids unnecessary string handling and conversions between strings and numbers.

Allows a choice of lookup facilities instead of tying you to something built-in. You can
use HexLookup, HexDns, another 3rd party component, or your own code to look up IP
addresses.

Clarifies network programming thinking. It enforces the distinction between domain names
and IP addresses and matches the way Internet communication actually works.

A "successful" validation does not guarantee a good
email address. Each validation stage simply presents an
opportunity to find a problem. If you get as far as SMTP
validation and it doesn't return an error, you get the highest
possible confidence in the address without actually trying to
send email to it. (That's why we call the Validate return value
a "confidence rating".) Some SMTP servers will not
complain about bad addresses, so you cannot know that an address
is good without actually sending email to it and getting a
response from your intended recipient.

Yes. HexValidEmail is designed to be robust enough for high
volumes. However, validating thousands of addresses can take
days if you do the validations sequentially. Most of this time
will be spent waiting on replies from remote servers. Thus, to
validate thousands of addresses, you will probably need to
optimize your validation techniques. (See below.)

Yes. HexValidEmail uses the DNS servers listed in your Windows
TCP/IP properties, so you may want to put your desired servers there.
Alternatively, you can use a registry
key to specify your server addresses.

HexValidEmail provides an option for sending VRFY and EXPN so
you can see the results with the SmtpSession
property. HexValidEmail ignores these results, however, and only
considers the response to the RCPT command. Occasionally you
will see cases in which the responses disagree.

HexValidEmail does not use VRFY and EXPN because they have
become quite unreliable as tests in recent years. Most
administrators disable them, but on different systems they give
different failure codes--even 2xx success codes sometimes. They
may also raise security flags for system administrators. We
recommend you leave this option off.

Socket components give you the ultimate in flexibility and control but
require you to handle all of the data transfer and higher-level protocol details yourself.

A
specific application protocol component, such as an HTTP component, takes care of the communication
and protocol details but limits you to its implementation of that one protocol.

HexTcpQuery strikes a balance between the two extremes: it does the sending and
receiving work, but leaves the higher protocols to you. As it happens, common protocols such as
Whois and Finger are trivial to implement, and HTTP is not far behind. (Our
TcpQuery sample demonstrates how.) Thus,
HexTcpQuery seeks to provide the best of both worlds--it does most of the work for you,
but gives you the flexibility to work with multiple protocols.

Strictly speaking, HexTcpQuery does not implement HTTP at
all--that's left to you.

Can it be used for HTTP/1.1? Yes, but with a few limitations
(it cannot maintain an open connection, for instance). We
recommend that you specify HTTP/1.0 in your queries. Using
HTTP/1.1 with HexTcpQuery will not provide much benefit over
HTTP/1.0 and may present some complications (such as content
chunking).