geos_one/archie
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Intial commit

Browse Source
This commit is contained in:
Mario Fetka
2024-05-27 16:13:40 +02:00
parent f8dc12b10a
commit d71d446104
2495 changed files with 539746 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
tcl-dp/doc/dp_accept.html Normal file
View File

@@ -0,0 +1,39 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="Author" content>
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
<title>dp_accept</title>
</head>
<body bgcolor="#C0C0C0" text="#000000" link="#0000EE"
vlink="#551A8B" alink="#FF0000">
<h3>dp_accept</h3>
<dl>
<dt><b>Syntax</b>&nbsp;</dt>
<dt>&nbsp;</dt>
<dt><tt>dp_accept </tt><em><tt>chanID</tt></em></dt>
<dt><tt></tt>&nbsp;</dt>
<dt><b>Comments</b></dt>
<dt><b></b>&nbsp;</dt>
<dt>This command is used to let a server TCP&nbsp;channel
listen for client connections.&nbsp; Do not use this
command on non-TCP&nbsp;channels. dp_accept blocks until
a client is connected.</dt>
<dt>&nbsp;</dt>
<dt>This command returns a list with the channel name of the
new client/server connection and the IP&nbsp;address of
the client which was accepted.</dt>
<dt>&nbsp;</dt>
<dt><b>Examples</b></dt>
<dt>&nbsp;</dt>
<dt><tt>set cliChan [lindex [dp_accept $myServerChan] 0]</tt></dt>
</dl>
</body>
</html>

47
tcl-dp/doc/dp_admin.html Normal file
View File

@@ -0,0 +1,47 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="Author" content>
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
<title>dp_admin</title>
</head>
<body bgcolor="#C0C0C0" text="#000000" link="#0000EE"
vlink="#551A8B" alink="#FF0000">
<h3>dp_admin</h3>
<p><b>Syntax</b></p>
<p><tt>dp_admin register </tt><em><tt>chanID</tt></em><tt>
?-check </tt><em><tt>checkCmd</tt></em><tt>?<br>
dp_admin delete </tt><em><tt>chanID</tt></em></p>
<p><b>Comments</b></p>
<p>dp_admin registers a channel so that RPCs or RDOs may be
performed using that channel. Call dp_admin delete before closing
an RPC channel in order to clean up the internal DP structures
associated with this channel. </p>
<p><em>checkCmd</em> is an optional Tcl script that will be
called with the RPC as the argument before the RPC is executed.
If <em>checkCmd</em> returns an error, the RPC will not be
executed and an error will be returned to the sender.</p>
<p>dp_admin returns 0 if all went well or 1 if there was an
error.</p>
<p><b>Examples</b></p>
<dl>
<dt><tt>dp_admin register $newRpcChan</tt></dt>
<dt><tt>dp_admin delete $oldRpcChan</tt></dt>
<dt>&nbsp;</dt>
</dl>
</body>
</html>

57
tcl-dp/doc/dp_connect.html Normal file
View File

@@ -0,0 +1,57 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="Author" content>
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
<title>dp_connect</title>
</head>
<body bgcolor="#C0C0C0" text="#000000" link="#0000EE"
vlink="#551A8B" alink="#FF0000">
<h3>dp_connect</h3>
<dl>
<dt><b>Syntax</b></dt>
<dt>&nbsp;</dt>
<dt><tt>dp_connect </tt><em><tt>channelType</tt></em><tt> </tt><em><tt>args</tt></em></dt>
<dt>&nbsp;</dt>
<dt><b>Comments</b></dt>
<dt>&nbsp;</dt>
<dt>dp_connect establishes a Tcl-DP&nbsp;channel.&nbsp; The <i>channelType</i>
is based on the channel types that are installed; the
base Tcl-DP&nbsp;package comes with TCP, UDP, IPM, serial
and email channels.&nbsp; The <i>args</i> are specific to
each channel type since TCP&nbsp;has completely different
options than serial ports do.&nbsp; Please see the
channel documentation for information on the available
arguments for that channel type.&nbsp; Once the channels
are established, one can configure them using the normal <b>fconfigure</b>
process.</dt>
<dt>&nbsp;</dt>
<dt>All I/O&nbsp;on these channels is performed using the
standard Tcl <b>puts/gets</b> or the Tcl-DP I/O commands:
<a href="dp_copy.html">dp_copy</a>, <a
href="dp_send.html">dp_send</a>, and <a
href="dp_recv.html">dp_recv</a>.</dt>
<dt>&nbsp;</dt>
<dt>dp_connect returns the ID of the new channel.</dt>
<dt>&nbsp;</dt>
<dt><b>Examples</b></dt>
<dt>&nbsp;</dt>
<dt><tt>set chan [dp_connect tcp -server true -myport 4466]</tt></dt>
<dt><tt>dp_connect tcp -host www.foo.bar.com -port 4466</tt></dt>
<dt><tt>dp_connect udp -host localhost -port 1906 -myport
1905</tt></dt>
<dt><tt>dp_connect serial -device serial1</tt></dt>
<dt><tt>dp_connect email -address foo@bar.com -identifier 100</tt></dt>
<dt><tt>dp_connect ipm -group 227.88.44.11 -myport 19000 -ttl
2</tt></dt>
<dt>&nbsp;</dt>
</dl>
</body>
</html>

48
tcl-dp/doc/dp_copy.html Normal file
View File

@@ -0,0 +1,48 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="Author" content>
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
<title>dp_copy</title>
</head>
<body bgcolor="#C0C0C0" text="#000000" link="#0000EE"
vlink="#551A8B" alink="#FF0000">
<h3>dp_copy</h3>
<p><b>Syntax</b>&nbsp;</p>
<p><tt>dp_copy ?-size </tt><em><tt>amount</tt></em><tt>?&nbsp;</tt><em><tt>srcChanId</tt></em><tt>
</tt><em><tt>destChanId</tt></em><tt> ?</tt><em><tt>destChanId2</tt></em><tt>
...?</tt></p>
<p><b>Comments</b></p>
<p>dp_copy allows bulk copying of information from one channel to
another.&nbsp; Notice that there can be more than one destination
channel (allowing for N-way copying).&nbsp; The size of the copy
can be specificied but it defaults to 4096 bytes.&nbsp; If the <em>amount</em>
requested is larger than the amount available in the source
channel, dp_copy may return less than the amount requested or
block, depending on the configuration of the source channel.</p>
<p>Note that dp_copy goes through the Tcl I/O layer, unlike <a
href="dp_send.html">dp_send</a> and <a href="dp_recv.html">dp_recv</a>.</p>
<dl>
<dt>dp_copy returns the number of bytes read from the source
channel.</dt>
<dt>&nbsp;</dt>
<dt><b>Examples</b></dt>
<dt>&nbsp;</dt>
<dt><tt>dp_copy -size 100 $src $dest</tt></dt>
<dt><tt>dp_copy $src $dest</tt></dt>
<dt>&nbsp;</dt>
</dl>
</body>
</html>

56
tcl-dp/doc/dp_netinfo.html Normal file
View File

@@ -0,0 +1,56 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="Author" content>
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
<title>dp_netinfo</title>
</head>
<body bgcolor="#C0C0C0" text="#000000" link="#0000EE"
vlink="#551A8B" alink="#FF0000">
<h3>dp_netinfo</h3>
<dl>
<dt><b>Syntax</b></dt>
<dt>&nbsp;</dt>
<dt><tt>dp_netinfo </tt><em><tt>option</tt></em><tt> </tt><em><tt>args</tt></em></dt>
<dt>&nbsp;</dt>
<dt><b>Comments</b></dt>
<dt>&nbsp;</dt>
<dt><i>Option</i>&nbsp;can be one of the following:</dt>
</dl>
<ul>
<li>-service</li>
<li>-address</li>
</ul>
<p>The -service option takes one argument: a service name or port
number.&nbsp; Enter a service name (i.e. &quot;http&quot; or
&quot;telnet&quot;) and dp_netinfo will return the active server
port for that service based on the system configuration.&nbsp; In
UNIX, this information is usually stored in /etc/services.&nbsp;
Likewise, you can give it a port number and it will return the
name of the service on that port.</p>
<p>The -address options allows one to translate from IP address
to hostname and vice versa.&nbsp; It also takes one
argument:&nbsp;an IP&nbsp;address (127.0.0.1) or a hostname
(www.foobar.com) and returns the cooresponding value.</p>
<p><b>Examples</b></p>
<dl>
<dt><tt>dp_netinfo -service http</tt></dt>
<dt><tt>dp_netinfo -service 80</tt></dt>
<dt><tt>dp_netinfo -address www.foobar.com</tt></dt>
<dt><tt>dp_netinfo -address 127.0.0.1</tt></dt>
<dt>&nbsp;</dt>
</dl>
</body>
</html>

53
tcl-dp/doc/dp_rdo.html Normal file
View File

@@ -0,0 +1,53 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="Author" content>
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
<title>dp_RDO</title>
</head>
<body bgcolor="#C0C0C0" text="#000000" link="#0000EE"
vlink="#551A8B" alink="#FF0000">
<h3>dp_RDO</h3>
<p><b>Syntax</b></p>
<p><tt>dp_RDO&nbsp;rdoChan ?-events </tt><em><tt>evtList</tt></em><tt>?
?-onerror </tt><em><tt>errScript</tt></em><tt>? ?-callback </tt><em><tt>callScript</tt></em><tt>?
rdoCmd ?args ...?</tt></p>
<p><b>Comments</b></p>
<p>RDO&nbsp;is akin to an RPC&nbsp;except there is no return
value. Since there is no return value, dp_RDO&nbsp;does not wait
for a response and therefore there is no need for the timeout
code that dp_RPC&nbsp;requires.</p>
<p>RDOs can be hard to debug because they generate no response at
all, even if something catastrophic happens. Therefore, one can
track errors by using <em>errScript</em>; the RDO sender's
errorInfo will be set to the RDO executer's errorInfo and <em>errScript</em>
will be called with the error message generated by the RDO as an
argument.</p>
<p>In the same vein, <em>callScript</em> will be evaluted when
the RDO has finished evaluting on the remote machine.</p>
<p>If both -onerror and -callback are specified, <em>callScript</em>
will be called unless the RDO generated an error.</p>
<p><b>Examples</b></p>
<dl>
<dt><tt>dp_RDO&nbsp;$myChan -events all puts stdout foobar</tt></dt>
<dt><tt>dp_RDO&nbsp;$myChan -onerror WhatError wackyProc</tt></dt>
<dt>&nbsp;</dt>
</dl>
</body>
</html>

34
tcl-dp/doc/dp_recv.html Normal file
View File

@@ -0,0 +1,34 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
<title>dp_recv</title>
</head>
<body>
<h3>dp_recv</h3>
<p><strong>Syntax</strong></p>
<pre>dp_recv <em>chanId</em></pre>
<p><strong>Comments</strong></p>
<p>dp_recv allows one to bypass the Tcl I/O layer and call the
channel's receive method directly. There are several problems
with Tcl's I/O system because it buffers data internally and it
is line or file-based.</p>
<p>dp_recv calls the channel's receive method <strong>once</strong>
and returns the received data.</p>
<p><strong>Examples</strong></p>
<pre>set a [dp_recv $chan]</pre>
</body>
</html>

68
tcl-dp/doc/dp_rpc.html Normal file
View File

@@ -0,0 +1,68 @@
<<<<<<< (null)="======">
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="Author" content>
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
<title>dp_RPC</title>
</head>
<body bgcolor="#C0C0C0" text="#000000" link="#0000EE"
vlink="#551A8B" alink="#FF0000">
<h3>dp_RPC</h3>
<p><b>Syntax</b></p>
<pre>dp_RPC&nbsp;<em>rpcChan</em> ?-timeout <em>amount</em> ?-timeoutReturn <em>script</em>?? ?-events <em>evtList</em>? <em>rpcCmd</em> ?args ...?</pre>
<p><b>Comments</b></p>
<p>dp_RPC allows one to send a Tcl expression to a remote Tcl
interpreter to be evaluated by it. <em>rpcChan</em> is a channel
opened with dp_connect and registered for RPCs with dp_admin.
Unlike dp_RDO, this command waits for a return code, although
because of the asynchronous nature of events and I/O, RPC return
codes are not guaranteed in any specific order. If one does not
need a return code, it is highly recommended that dp_RDO&nbsp;be
used instead; it is much faster and far less complex.</p>
<p>The timeout <em>amount</em> specifies how long
dp_RPC&nbsp;will block before returning an error and is in
milliseconds. <em>script</em> is the script to evaluate if the
RPC&nbsp;times out. Specifying a timeout script without a timeout
value is invalid. The prototype for the timeoutReturn script is
as follows:</p>
<pre>proc errorHandler {channelName} {}</pre>
<p><em>evtList</em> is a normal Tcl event list that tells
DP&nbsp;which events to respond to while waiting for the
RPC&nbsp;to return. See the Tcl documentation on events for valid
parameters.</p>
<p>dp_RPC&nbsp;returns the return value of the <i>rpcCmd</i>.</p>
<hr>
<p>If you are using RPCs with just tclsh, an RPC will not execute
asynchronously due to the fact that Tcl relies on
Tcl_DoOneEvent() to process events. It is recommended that you
use wish or add a vwait command in your script to force Tcl into
an event loop. As an example, if you send an RPC to puts
&quot;foobar&quot;, the receiving intrepreter will not print
&quot;foobar&quot; until update is called.</p>
<hr>
<p><b>Examples</b></p>
<pre>dp_RPC&nbsp;$myChan puts stdout hello
dp_RPC $myChan -timeout 100 puts stdout foo
dp_RPC&nbsp;$myChan -timeout 100 -timeoutReturn &quot;set a 1&quot; -events all puts stdout hello</pre>
</body>
</html>

33
tcl-dp/doc/dp_send.html Normal file
View File

@@ -0,0 +1,33 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="Author" content>
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
<title>dp_send</title>
</head>
<body>
<h3>dp_send</h3>
<p><b>Syntax</b></p>
<pre>dp_send <i>chanID</i><em> string</em></pre>
<p><strong>Comments</strong></p>
<p>dp_send allows direct output onto a channel, bypassing Tcl's
I/O layer. It calls the given channel's output method until all
of <em>string </em>has been sent.</p>
<p>dp_send returns the amount of data sent.</p>
<p><font color="#000000"><strong>Examples</strong></font></p>
<p><font color="#000000">dp_send $chan [read $file1024]</font></p>
</body>
</html>

88
tcl-dp/doc/email.html Normal file
View File

@@ -0,0 +1,88 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="Author" content>
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
<title>Email Channel</title>
</head>
<body bgcolor="#C0C0C0" text="#000000" link="#0000EE"
vlink="#551A8B" alink="#FF0000">
<h3>Email Channel</h3>
<p><b>Syntax</b></p>
<p><tt>dp_connect email -address </tt><em><tt>email_adress</tt></em><tt>
-identifier </tt><em><tt>unique_id</tt></em></p>
<p><b>Comments</b></p>
<p><i>email_address</i> is the address to which outgoing messages
will be sent, and from which they will be received&nbsp;</p>
<p><i>unique_id</i> must be a unique identifier that will be used
to generate the files associated with the email channels (see
below). It is mandatory when opening the first email channel, and
optional when opening subsequent ones. If given, the value of the
parameter has to be the same for all opened email channels.
Different identifiers can be used to open email channels in
independent processes that run dp. The value of the identifier
can also be used to recover information from the email files
after a crash of dpsh (this feature is not implemented).&nbsp;</p>
<p>Incoming email messages will be filtered and the relevant ones
will be directed toward the files associated with the email
channels. All incoming messages will be also forwarded to the
address(es) given in the original ~/.forward file or, if this did
not exist, to the user's mailbox. The messages sent through email
channels will always have &quot;email channel&quot; in their
subject line.&nbsp;</p>
<p>Opening several email channels associated with the same
address is possible, but an incoming message will be delivered
only to one of them.&nbsp;</p>
<p>An email channel is always writable, and will never block. The
channel specific options are the following:&nbsp;</p>
<ul>
<li>peek (boolean) - usual interpretation&nbsp;</li>
<li>sequence (boolean) - if set, a line of the form
&quot;Sequence: &lt;sequence_number&gt;&quot; will be
inserted after the subject line of outgoing
messages.&nbsp;</li>
</ul>
<p><b>Temporary Files&nbsp;</b></p>
<p>When the first email channel is opened file ~/.forward is
created (or extended, if it exists already) to include dpfilter.
Dpfilter is an utility that selectes incoming email messages for
which an email channel was opened. These will be stored in files
~/.emailSpool&lt;unique_id&gt;. File
~/.emailSeek&lt;unique_id&gt; serves as an index for
~/.emailSpool&lt;unique_id&gt; ~/.emailChannel&lt;unique_id&gt;
stores the addresses corresponding to the opened email channel.
To synchronize the activity of dpsh and dpfilter, a symbolic link
~/.emailLock&lt;unique_id&gt; is sometimes created.&nbsp;</p>
<p>If dpsh crashes with at least one open email channel, one
should delete files ~/.email*, and restore the initial state or
delete the ~/.forward file.&nbsp;</p>
<p><b>Examples&nbsp;</b></p>
<dl>
<dt><tt>set first [dp_connect email -address root -identifier
100]&nbsp;</tt></dt>
<dt><tt>set second [dp_connect email -address
foobar@cs.foo.edu]&nbsp;</tt></dt>
<dt><tt>fconfigure $first -peek yes -sequence yes&nbsp;</tt></dt>
</dl>
</body>
</html>

395
tcl-dp/doc/filter.html Normal file
View File

@@ -0,0 +1,395 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="Author" content>
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
<title>Plugin Filter Channel</title>
</head>
<body bgcolor="#C0C0C0" text="#000000" link="#0000EE"
vlink="#551A8B" alink="#FF0000">
<h3>Plug-In Filter Channel</h3>
<p><b>Syntax</b></p>
<p><tt>dp_connect plugfilter -channel </tt><em><tt>channel_name</tt></em><tt>
-infilter </tt><em><tt>filter_name</tt></em><tt> -outfilter </tt><em><tt>filter_name</tt></em></p>
<p><b>Comments</b></p>
<p>Arguments:&nbsp;</p>
<ul>
<li><i>channel_name</i> is the name of an already existing
channel (the subordinated channel), whose input and/or
output will be filtered. Using filters, an unlimited
number of channels can be composed to form a linear chain
that transparently performs complex functions (e.g.
sequencing, encrypting/decrypting, transcoding,
etc.).&nbsp;</li>
<li><i>filter_name</i> is the name of a registered filter
function (see below). Neither the value for -infilter,
nor for -outfilter is mandatory. If they are missing, the
corresponding filter function will be <b>identity</b>.</li>
</ul>
<dl>
<dt><b>Description of Filter Functions</b></dt>
<dt>&nbsp;</dt>
<dd>Prototype: <tt>int Filter (char *inBuf, int inLength,
char **outBuf, int *outLength, void **data, Tcl_Interp
*interp, int mode)&nbsp;</tt><p>Arguments: We provide
below the parameters' default interpretation. For the
other cases, please refer to the description of the mode
parameter below.</p>
<ul>
<li>(in) <tt>inBuf</tt>: Points to the start of the
input buffer. It is assumed that the filter
consumes the entire input. If it is not possible
to generate filtered output for all the input
data, part of it can be buffered
internally.&nbsp;The responsability of freeing
the buffer always pertains to the <font size="3"
face="Courier New">DP</font> code, and not to the
filter.</li>
<li>(in) <tt>inLength</tt>: The length of the input
buffer.&nbsp;</li>
<li>(out) <tt>outBuf</tt>: Whenever the filter will
generate output, the address of the buffer must
be stored in <font size="2" face="Courier New">*outbuf</font>.
The parameter is ignored by the <font
face="Courier New">DP</font> code when <font
size="2" face="Courier New">*outLength</font> is
set to 0. Unless the value of mode is <font
face="Courier New">DP_FILTER_GET</font>, it is
the responsability of the <font
face="Courier New">DP</font> code to manage the
buffer. When mode is <font face="Courier New">DP_FILTER_GET</font>,
it is the responsability of the filter function
to manage the buffer.</li>
<li>(out) <tt>outLength</tt>: The length of the
output buffer. If there is no output, <font
size="2" face="Courier New">*outLength</font>
must be set to 0.</li>
<li>(in) <font size="2" face="Courier New">data</font>:
If filter functions need persistent state
associated with the streams they filter, they can
store a pointer to these structures in <font
size="2" face="Courier New">*data</font>. Before
the first call to the filter function, the
plug-in channel code initializes <font size="2"
face="Courier New">*data</font> with <font
face="Courier New">NULL</font>. The filter
function has full responsability in managing the
memory zone pointed to by <font size="2"
face="Courier New">*data.</font> In particular,
the filter should free all the allocated space
when the value of the mode parameter is <font
face="Courier New">DP_FILTER_CLOSE.</font></li>
<li>(in) <font size="2" face="Courier New">interp</font>:
Pointer to the tcl interpreter in which the
filter channel was created. It can be used to
create filters that evaluate arbitrary tcl
expressions (see, for example. the tclfilter
function below).</li>
<li>(in) <tt>mode</tt>: This parameter specifies how
the other arguments must be interpreted. Unless
specified otherwise, the default interpretation
of the other parameters must be used.</li>
<li><ul>
<li><tt>DP_FILTER_NORMAL</tt>: The <font
size="2" face="Courier New">mode</font>
parameter will have this value when the <font
size="2" face="Courier New">-buffering</font>
option of the filter channel has been set
to <font size="2" face="Courier New">line</font>
or <font size="2" face="Courier New">full</font>.</li>
<li><tt>DP_FILTER_FLUSH</tt>: The filter is <font
size="2" face="Courier New">encouraged</font>
to generate output, even if this would
not normally be the case. The filter can
ignore this argument and behave like <font
size="2" face="Courier New">mode</font>
was <tt>DP_FILTER_NORMAL</tt>. The mode
parameter will have this value when the <font
size="2" face="Courier New">-buffering</font>
option of the filter channel has been set
to <font size="2" face="Courier New">none</font>.&nbsp;</li>
<li><dl>
<dt><font face="Courier New">DP_FILTER_EOF</font>:
This value of the parameter
signals that no more data will be
received from the subordinated
channel. At this point, the
filter function must generate all
the output it can, and free all
its internal buffers.</dt>
</dl>
</li>
</ul>
<ul>
<li><tt>DP_FILTER_CLOSE</tt>: This value of
the parameter signals that the filter
channel is about to be closed, and this
is the last call to the filter function.
The filter must deallocate all its
internal data structures, and generate
all the output it can.</li>
<li><tt>DP_FILTER_SET</tt>: All parameters
are ignored, except for <font size="2"
face="Courier New">inBuf</font> and <font
size="2" face="Courier New">inLength</font>.
In this case the input buffer is a string
that is passed &quot;as is&quot; by Tcl
from the <font size="2"
face="Courier New">fconfigure
&lt;channel&gt; -[inset | outset]
&lt;string&gt;</font> command. The filter
function can use the string to set its
internal variables. For example, this
mechanism could be used to set a
different pgp key for each channel.&nbsp;</li>
<li><tt>DP_FILTER_GET</tt>: All parameters
are ignored, except for <font size="2"
face="Courier New">outBuf</font>. The
filter function must store in <font
size="2" face="Courier New">*outBuf</font>
the address of a null-terminated string
that describes its internal state. The
string is read only once by <font
face="Courier New">DP</font>, immediately
after the filter returns. This is the
only case when the filter function has to
manage the memory zone whose address was
stored in *outbuf; which is done to avoid
unnecessary reconstructions of the state
string.</li>
</ul>
</li>
</ul>
<p>Return value: If no error is detected, the return
value must be zero. A non-zero return value signals an
error, if needed, <font size="2" face="Courier New">POSIX</font>
error codes can be used to indicate the type of the
error.</p>
<p>Before being used, a filter function has to be
registered by calling function <tt>Dp_RegisterPlugInFilter</tt>.
<tt>TCL_OK</tt> is returned upon successful completion of
registration.&nbsp;</p>
<p>Prototype: <tt>int Dp_RegisterPlugInFilter (Tcl_Interp
interp, Dp_PlugInFilter *newPlugInPtr)&nbsp;</tt></p>
<p>Arguments:&nbsp;</p>
<ul>
<li><em>interp</em> is the pointer to the interpreter
in which the registration wil take place&nbsp;</li>
<li><em>newPlugInPtr</em> is a pointer to a filter
function defined as specified above.&nbsp;</li>
</ul>
<p>Filter functions can also be pre-registered, by adding
them to the array <b>builtInPlugs</b><i> </i>in file <b>generic/dpChan.c</b>,
and recompiling Tcl-DP. As of now, the following plug-in
filters are provided (unless specified otherwise, the
filters have no internal parameters):</p>
<ul>
<li>identity: Used as default value for a filter
function that was not defined explicitly.
Property: identity(X) = X.&nbsp;</li>
<li>plug1to2: The input string is filtered by
replacing each character of the string with two
copies of itself. Example:
Plug1to2(&quot;abc&quot;) = &quot;aabbcc&quot;.</li>
<li>plug2to1: The input string is filtered by
selecting the characters that have even indices.
Example: Plug2to1(&quot;abcdef&quot;) =
&quot;ace&quot;.</li>
<li>xor: An arbitrary, non-empty parameter string has
to be provided as an internal argument before
first using the filter. The input bytes will be
xor'd with the bytes in the parameter, taken in
circular order. This order will be preserved
between succesive calls. The same string must be
used for both encoding and decoding. Example:
xor(&quot;abc&quot;, &quot;12&quot;) = xyz, where
x = 'a' ^ '1', y = 'b' ^ '2', z = 'c' ^ '1'.</li>
<li>packon: Adds a header of 6 bytes to each packet
that is written to or read from the underlying
channel. The header contains a right-aligned
nonnegative integer in base 10; the integer is
padded to the left with non-significant zeroes.
Normally a packet is the amount of data that is
written to (read from) the underlying channel at
one time. (Note: If the amount of data is bigger
than the capacity of Tcl's internal buffers
(usually 4k), spurious packets will be
generated.) Example: packon(&quot;abc&quot;) =
&quot;000003abc&quot;.</li>
<li>uuencode: Same functionality as Unix uuencode;
converts a binary file into a specially formatted
file containg a subset of the ASCII character
set. Example: uuencode(&quot;abc&quot;) =
&quot;begin 740 uufilter\n$86C&quot;O\\\n\n
\nend\n&quot; ('\n' stands for line feed, and
'\\'stands for backslash).</li>
<li>uudecode: Same functionality as Unix uudecode.
Example: uudecode(&quot;begin 740
uufilter\n$86C&quot;O\\\n\n \nend\n&quot;) =
&quot;abc&quot;.</li>
<li><dl>
<dt>tclfilter: Allows the user to use any tcl
function to implement a filter. The tcl
filter takes two arguments, and is
assumed to consume the whole input (and
buffer it, if necessary). The first
argument is the (possibly zero-length)
input string, The second argument can
only have the values &quot;normal&quot;,
&quot;flush&quot;, &quot;close&quot;,
&quot;eof&quot; and corresponds to the
mode <font size="2" face="Courier New">parameter</font>
above. The output value is a (possibly
zero-length) string that represents the
first use. Arguments: the name of the tcl
procedure must be set up before the first
use.</dt>
</dl>
</li>
<li>hexout: Given a string of even length containing
the characters 0..9, a..f, A..F this filter
translates it into a sequence of bytes whose
hexadecimal representation is the given string.
Example: hexout(&quot;00Ff&quot;) will generate
two bytes, the first one having all bits set to
zero, the second one having all bites set to 1.</li>
<li><dl>
<dt>hexin: Has the opposite effect to hexout.</dt>
</dl>
</li>
</ul>
</dd>
</dl>
<p><b>Filters as Independent Channels</b></p>
<p>When some peculiar requirement or Tcl's idiosyncracies make it
inconvenient or impossible to implement some filters using
plug-in channels, one can obtain the desired functionality by
creating a standalone filter channel. We provide two such
examples:</p>
<p>identity: This channel reproduces the functionality of the
identity plug-in filter. It is provided as a skeleton that can be
modified to implement more complex filters. This channel does not
accept any non-standard options. Note: do not confuse the
identity (standalone) filter channel with the identity filter
function.</p>
<p>packoff: This filter identifies packets generated by the
packon plug-in filter (see above) and separates them from the
input stream, returning them separately. Since this operation
makes sense only when reading data, this channel is not writable.
This channel does not accept any non-standard options.</p>
<p><b>Properties of the Provided In-Built Filter Functions</b></p>
<p>Plug1to2(Plug2to1(X)) = X.&nbsp;</p>
<p>Plug2to1(Plug1to2(X)) = X.&nbsp;</p>
<p>xor(xor(X,Y),Y) = X.</p>
<p>packon(packoff(X)) = packoff(packon(X)).</p>
<p>uudecode(uuencode(X)) = X.</p>
<p>hexin(hexout(X)) = X</p>
<p>hexout(hexin(X)) = X</p>
<p>hexin(hexout(X)) != hexout(hexin(X))</p>
<p><b>Order of Operations</b></p>
<p>When flushing or closing a sequence of channels linked through
filters, one should follow the flow of data.&nbsp;</p>
<p>Example: filter1--&gt;filter2--&gt;TCP_channel&nbsp;</p>
<p>When closing this composite channel the sequence of operations
should be&nbsp;</p>
<p><tt>close $filter1<br>
close $filter2<br>
close $tcp_channel</tt></p>
<p><b>Configuration of Filter Channels&nbsp;</b></p>
<p>The subordinated channel and the input and output filter
functions of a filter channel can not be changed.</p>
<p>The peek option is forwarded to the subordinated channel, but
it does not act on the filter channel itself.&nbsp;</p>
<p>There are two options, <font size="2" face="Courier New">-inset</font>
and <font size="2" face="Courier New">-outset</font>, that can be
used to transmit arguments to the input and output filter
functions, respectively. The argument of <font size="2"
face="Courier New">-inset</font> and <font size="2"
face="Courier New">-outset</font> is a string that will be passed
to the corresponding filter function &quot;as is&quot;. It is the
responsability of the filter function to interpret the
string.&nbsp;</p>
<p>If the user wishes to change an option for the subordinated
channel, this must be done directly.&nbsp;</p>
<p>A filter channel will always be non-blocking. Seek is not
allowed. A plug-in filter channel will always be both readable
and writeable, but the real behavior will depend on the
characteristics of the internal buffering of filter functions,
and on the behavior of the subordinated channel.&nbsp;</p>
<p>Note: though tcl itself can not handle binary data, the
plug-in filters can. Care must be taken to set the <font size="2"
face="Courier New">-translation </font>option to binary for the
appropriate channels.</p>
<p><b>Composition of Filters</b></p>
<p>Both plug-in and independent channel filters can be composed
with no restrictions.</p>
<p><b>Examples&nbsp;</b></p>
<dl>
<dt><tt>dp_connect plugfilter -channel tcp1 -infilter
plug2to1 -outfilter plug1to2<br>
<br>
dp_connect plugfilter -channel email0 -outfilter pgp
-infilter un_pgp<br>
<br>
set xout [dp_connect plugfilter -channel file540
-outfilter uuencode<br>
fconfigure $xout -translation binary<br>
set xxout [dp_connect plugfilter -channel $xout
-outfilter xor]<br>
fconfigure $xxout -translation binary -outset &quot;my
secret string goes here&quot;<br>
<br>
set xin [dp_connect plugfilter -channel file100 -infilter
tclfilter]<br>
fconfigure $xin -inset MyTclProcedure<br>
<br>
dp_connect packoff -channel tcp10</tt></dt>
</dl>
<p>For more details, please refer to the tests/plugin2.test file
in the standard distribution.</p>
<p>&nbsp;</p>
</body>
</html>

105
tcl-dp/doc/index.html Normal file
View File

@@ -0,0 +1,105 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="Author" content="Mike Perham">
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
<title>Tcl-DP Command Documentation</title>
</head>
<body bgcolor="#C0C0C0" text="#000000" link="#0000EE"
vlink="#551A8B" alink="#FF0000">
<h2>Tcl-DP Documentation</h2>
<hr>
<h3>Tcl-DP Commands</h3>
<ul>
<li><a href="dp_accept.html">dp_accept</a> - accept a TCP
client connection</li>
<li><a href="dp_admin.html">dp_admin</a> -
register/unregister a DP&nbsp;channel for RPC/RDOs</li>
<li><a href="dp_connect.html">dp_connect</a> - open a
Tcl-DP&nbsp;channel</li>
<li><a href="dp_copy.html">dp_copy</a> - perform a bulk copy
from one channel to another</li>
<li><a href="dp_netinfo.html">dp_netinfo</a> - allows access
to TCP, DNS&nbsp;and SMTP information</li>
<li><a href="dp_rdo.html">dp_RDO</a> - perform a remote
procedure call without return value</li>
<li><a href="dp_recv.html">dp_recv</a> - get data from a
channel</li>
<li><a href="dp_rpc.html">dp_RPC</a>&nbsp;- perform a remote
procedure call</li>
<li><a href="dp_send.html">dp_send</a> - send data through a
channel</li>
</ul>
<hr>
<h3>Tcl-DP&nbsp;Library Functions</h3>
<ul>
<li><b>RPC</b><ul>
<li><a href="makerpcserver.html">dp_MakeRPCServer</a>
- create TCP&nbsp;RPC&nbsp;server channel</li>
<li><a href="makerpcclient.html">dp_MakeRPCClient</a>
- create TCP&nbsp;RPC&nbsp;client channel</li>
</ul>
</li>
<li><strong>Distributed Objects</strong></li>
<li><a href="sample.html"><strong>Sample Applications</strong></a></li>
</ul>
<hr>
<h3>Tcl-DP&nbsp;Channels</h3>
<ul>
<li><a href="tcp.html">TCP</a></li>
<li><a href="udp.html">UDP</a></li>
<li><a href="ipm.html">IPM</a></li>
<li><a href="serial.html">Serial</a></li>
<li><a href="email.html">Email</a></li>
<li><a href="filter.html">Filters</a></li>
</ul>
<hr>
<h3>Tcl-DP v3.x Obsolete Functions</h3>
<ul>
<li>dp_address - obsolete, use dp_connect or fconfigure to
setup UDP/IPM destinations</li>
<li>dp_receive - use &quot;gets chanID&quot; and &quot;puts
chanID&quot;</li>
<li>dp_send - (not the same as the 4.0 command)</li>
<li>dp_packetReceive</li>
<li>dp_packetSend</li>
<li>dp_readbinary</li>
<li>dp_writebinary</li>
<li>dp_receiveFrom</li>
<li>dp_sendTo</li>
<li>dp_whenidle - use &quot;after idle ?script?&quot;</li>
<li>dp_hostname - use &quot;info hostname&quot;</li>
<li>dp_waitvariable - use &quot;vwait ?variable?&quot;</li>
<li>dp_update - use &quot;update ?idletasks?&quot;</li>
<li>dp_socketOption - use &quot;fconfigure chanID
?option?&quot;</li>
<li>dp_shutdown - use &quot;close chanID&quot;</li>
<li>dp_isready - obsolete in event-driven I/O</li>
<li>dp_filehandler - use &quot;fileevent chanID ?type?
?script?&quot;</li>
<li>dp_fupdate - obsolete, all channels should be opened with
dp_connect</li>
<li>dp_closesocket - use &quot;close chanID&quot;</li>
<li>dp_ProcessRPCCommand - obsolete in wish, use
&quot;update&quot; in tclsh</li>
</ul>
</body>
</html>

64
tcl-dp/doc/ipm.html Normal file
View File

@@ -0,0 +1,64 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="Author" content>
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
<title>IPM Channel</title>
</head>
<body bgcolor="#C0C0C0" text="#000000" link="#0000EE"
vlink="#551A8B" alink="#FF0000">
<h3>IP&nbsp;Multicast Channel</h3>
<p><b>Syntax</b></p>
<p><tt>dp_connect ipm -group </tt><em><tt>ipAddr</tt></em><tt>
-myport </tt><em><tt>myPort</tt></em><tt> -ttl </tt><em><tt>numHops</tt></em></p>
<p><b>Comments</b></p>
<p>IPM is the multicast version of UDP.&nbsp; It allows any
number of machines to join a group and if a message is sent to
the group address, all the machines will hear it.</p>
<ul>
<li><i>ipAddr</i> is the IP&nbsp;address of the group.&nbsp;
This <b>must</b> be an multicast address in the range of
224.0.0.0 to 239.255.255.255.</li>
<li><i>myPort</i> is the local port and is optional.</li>
<li><i>numHops</i> is the Time To Live value.&nbsp; The
multicast packets will only cross <i>numHops</i>-1
routers after which they are discarded by the
router.&nbsp; To keep all multicast data on the local
subnet, use a ttl value of 1.&nbsp; Proper netiquette
maintains that this number be as low as possible.&nbsp;
It is optional and defaults to 1.</li>
</ul>
<hr>
<p>One can add and drop IPM group memberships using the
fconfigure -group command. See below for examples and please note
the use of the plus and minus symbol to signify add or drop. An
IPM channel can be a member of any number of multicast groups
(although it is usually limited by the OS to 20) so it is not
necessary to drop a group in order to add a new one.</p>
<hr>
<p><b>Examples</b></p>
<dl>
<dt><tt>dp_connect ipm -group 224.76.0.119</tt></dt>
<dt><tt>dp_connect ipm -group 225.23.120.87 -ttl 3</tt></dt>
<dt><tt>dp_connect ipm -group 238.1.1.1 -port 1905 -ttl 255</tt></dt>
<dt><tt>fconfigure $ipmChan -group +226.54.3.2</tt></dt>
<dt><tt>fconfigure $ipmChan -group -232.56.198.6</tt></dt>
</dl>
</body>
</html>

44
tcl-dp/doc/makerpcclient.html Normal file
View File

@@ -0,0 +1,44 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="Author" content>
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
<title>MakeRPCClient</title>
</head>
<body bgcolor="#C0C0C0" text="#000000" link="#0000EE"
vlink="#551A8B" alink="#FF0000">
<h3>dp_MakeRPCClient</h3>
<p><b>Syntax</b></p>
<p><tt>dp_MakeRPCClient </tt><em><tt>host</tt></em><tt>&nbsp;</tt><em><tt>port</tt></em><tt>&nbsp;?</tt><em><tt>checkCmd</tt></em><tt>?</tt></p>
<p><b>Comments</b></p>
<p>This is a Tcl wrapper procedure for creating a
TCP&nbsp;RPC&nbsp;client. If you need a client of a different
channel type, you can use this procedure as a template in order a
procedure for your own channel type.</p>
<ul>
<li><i>host</i> is the IP address or hostname of the server.</li>
<li><i>port</i> is the server port to connect.</li>
<li><i>checkCmd</i> is identical to the parameter of the same
name in <a href="makerpcserver.html">dp_MakeRPCServer</a>.
It defaults to none.</li>
</ul>
<p><b>Examples</b></p>
<dl>
<dt><tt>dp_MakeRPCClient xyzzy.foo.com 5150</tt></dt>
<dt><tt>dp_MakeRPCClient foo.bar.com 4123 myCheckerProc</tt></dt>
</dl>
</body>
</html>

50
tcl-dp/doc/makerpcserver.html Normal file
View File

@@ -0,0 +1,50 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="Author" content>
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
<title>dp_MakeRPCServer</title>
</head>
<body bgcolor="#C0C0C0" text="#000000" link="#0000EE"
vlink="#551A8B" alink="#FF0000">
<h3>dp_MakeRPCServer</h3>
<p><b>Syntax</b></p>
<p><tt>dp_MakeRPCServer </tt><em><tt>port</tt></em><tt>
?loginFunc? ?checkCmd?</tt></p>
<p><b>Comments</b></p>
<p>This is a Tcl wrapper procedure for the creating an
RPC&nbsp;server in one command. The arguments have not been
changed from 3.x in order to preserve compatibility. This
procedure creates an RPC TCP&nbsp;server. If you need an
RPC&nbsp;server on another type of channel, you can use this
procedure as a template for writing your own.</p>
<ul>
<li><i>port</i> is the TCP&nbsp;port to use for the
RPC&nbsp;server.</li>
<li><i>loginFunc</i> is the procedure called when a client
connects to the server. Usually, this command checks for
necessary authorization. dp_CheckHost, which is provided
in the rpc.tcl library, is the default value.</li>
<li><i>checkCmd</i> can be used as a filter to check the RPCs
before they are executed.</li>
</ul>
<p><b>Syntax</b></p>
<dl>
<dt><tt>dp_MakeRPCServer 5150</tt></dt>
<dt><tt>dp_MakeRPCServer 4149 myLogin CheckThisPal</tt></dt>
</dl>
</body>
</html>

33
tcl-dp/doc/sample.html Normal file
View File

@@ -0,0 +1,33 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
<title>Sample Applications</title>
</head>
<body bgcolor="#C0C0C0">
<h3>Sample Applications</h3>
<p>As an trivial example of what Tcl-DP can do, we have included
several samples of how one can use Tcl-DP. In the <strong>examples</strong>
subdirectory, there is:</p>
<ul>
<li>A Tk whiteboard application</li>
<li>An FTP-like protocol for file transfer between two Tcl
interpreters</li>
<li>A group text conferencing system and, of course,</li>
<li>Tic-Tac-Toe</li>
</ul>
<p>Note that the whiteboard and conferencing system would both
benefit by switching the network protocol from TCP to IPM but
since dp_MakeRPC{Server,Client} both use TCP, that task is left
to the reader.</p>
</body>
</html>

54
tcl-dp/doc/serial.html Normal file
View File

@@ -0,0 +1,54 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="Author" content>
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
<title>Serial Channel</title>
</head>
<body bgcolor="#C0C0C0" text="#000000" link="#0000EE"
vlink="#551A8B" alink="#FF0000">
<h3>Serial Channel</h3>
<p><b>Usage</b></p>
<p><tt>dp_connect serial -device </tt><em><tt>serDev</tt></em><tt>
-block </tt><em><tt>bBlock</tt></em><tt> -readonly </tt><em><tt>bRead</tt></em></p>
<p><b>Comments</b></p>
<p><i>serDev</i> is the Tcl-DP&nbsp;name of the given serial
port. In order to make Tcl-DP&nbsp;scripts as portable as
possible, DP&nbsp;names the serial ports &quot;serial1&quot;,
&quot;serial2&quot;, &quot;serial3&quot;, etc. The DP&nbsp;name
is then translated internally to the OS&nbsp;specific name (COM1,
/dev/ttyb, etc).</p>
<ul>
<li><i>bBlock</i><b><i> </i></b>is a boolean that determines
whether the serial port will block while waiting for
input. The default is true.</li>
<li><i>bRead</i> is a boolean that determines whether the
serial port will be opened with readonly access. Often,
UNIX&nbsp;serial ports are writable only by the
superuser. If this is the case, using this flag will at
least allow one to possibly read from the serial port.
The default is false.</li>
</ul>
<p>Options like baudrate, parity and character size can be set
using fconfigure after the channel is opened.</p>
<p><b>Examples</b></p>
<dl>
<dt><tt>dp_connect serial -device serial2</tt></dt>
<dt><tt>dp_connect serial -device serial1 -readonly true</tt></dt>
</dl>
</body>
</html>

61
tcl-dp/doc/tcp.html Normal file
View File

@@ -0,0 +1,61 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="Author" content>
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
<title>TCP Channel</title>
</head>
<body bgcolor="#C0C0C0" text="#000000" link="#0000EE"
vlink="#551A8B" alink="#FF0000">
<h3>TCP Channel</h3>
<p><b>Syntax</b></p>
<p><tt>dp_connect tcp -server </tt><em><tt>bool</tt></em><tt>
-host </tt><em><tt>hostname</tt></em><tt> -port </tt><em><tt>thePort</tt></em><tt>
-myport </tt><em><tt>myPort</tt></em><tt> -myaddr </tt><em><tt>addr</tt></em><tt>
-async </tt><em><tt>bAsync</tt></em></p>
<p><b>Comments</b></p>
<p>A TCP connection logically breaks down into two types: server
and client. For an exchange to take place, there must be one of
each. <i>bool</i> defaults to false.</p>
<ul>
<li><b>Server</b><p>A server channel must have a minimum of
-server true and -myport myPort specified.<br>
<i>myPort</i> is the port that the server will listen on
while waiting for client connections.<br>
All other options save -myaddr are invalid for servers.</p>
</li>
</ul>
<ul>
<li><b>Client</b><p>A client must specify the host and port,
at minimum.<br>
<i>hostname</i> is the IP address or hostname of the
server machine.<br>
<i>thePort</i> is the port the server resides on.<br>
If <i>bAsync</i> is true, the socket connection is made
asynchronously.<br>
<i>myAddr</i> and <i>myPort</i> are the IP
address/hostname and the port number of the client,
respectively.&nbsp;</p>
</li>
</ul>
<p><b>Examples</b></p>
<p><tt>dp_connect tcp -server true -myport 1025<br>
dp_connect tcp -host foo.com -port 1025<br>
dp_connect tcp -server true -myaddr foo.bar.com -myport 5150<br>
dp_connect tcp -host foo.bar.com -port 5150 -async true</tt></p>
</body>
</html>

57
tcl-dp/doc/udp.html Normal file
View File

@@ -0,0 +1,57 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="Author" content>
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
<title>UDP Channel</title>
</head>
<body bgcolor="#C0C0C0" text="#000000" link="#0000EE"
vlink="#551A8B" alink="#FF0000">
<h3>UDP Channel</h3>
<p><b>Syntax</b></p>
<p><tt>dp_connect udp -host </tt><em><tt>hostname</tt></em><tt>
-port </tt><em><tt>thePort</tt></em><tt> -myaddr </tt><em><tt>addr</tt></em><tt>
-myport </tt><em><tt>port</tt></em></p>
<p><b>Comments</b></p>
<p>UDP&nbsp;is a stripped down version of TCP.&nbsp;
UDP&nbsp;does the bare necessities and nothing more:&nbsp;it does
not do error checking, reliabilitiy or packet sequencing.&nbsp;
It is, however, much faster than TCP and allows dynamic
configuration of the destination IP&nbsp;address and port.</p>
<dl>
<dt><i>hostname</i> is the IP address or DNS&nbsp;hostname of
the destination machine and is optional.</dt>
<dt><i>thePort</i> is the destination port address and is
optional.</dt>
<dt><i>addr</i> is the local IP&nbsp;address and is optional.</dt>
<dt><i>port</i> is the local port and is optional.</dt>
<dt>&nbsp;</dt>
<dt>Note that if no arguments are given, &quot;dp_connect
udp&quot; will open a UDP&nbsp;socket but <b>fconfigure</b>
will need to be run on the channel before data can be
sent through it since the socket does not have a
configured destination.</dt>
</dl>
<p><b>Examples</b></p>
<dl>
<dt><tt>dp_connect udp</tt></dt>
<dt><tt>dp_connect udp -host foo.com -port 1025<br>
dp_connect udp -myaddr foo.bar.com -myport 5150<br>
dp_connect udp -host foo.bar.com -port 5150 -myaddr
foo.org -myport 1066</tt></dt>
</dl>
</body>
</html>