File: connect.man

package info (click to toggle)
tcllib 1.10-dfsg-3
  • links: PTS
  • area: main
  • in suites: lenny
  • size: 17,708 kB
  • ctags: 6,122
  • sloc: tcl: 106,354; ansic: 9,205; sh: 8,707; xml: 1,766; yacc: 753; makefile: 115; perl: 84; f90: 84; python: 33; ruby: 13; php: 11
file content (170 lines) | stat: -rw-r--r-- 5,695 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
[comment {-*- tcl -*- doctools manpage}]
[manpage_begin transfer::connect n 0.1]
[copyright {2006 Andreas Kupries <andreas_kupries@users.sourceforge.net>}]
[moddesc   {Data transfer facilities}]
[titledesc {Connection setup}]
[require Tcl               8.4]
[require snit              [opt 1.0]]
[require transfer::connect [opt 0.1]]
[description]
[keywords transfer channel connection passive active]
[para]

This package provides objects holding enough information to enable
them to either connect to a counterpart, or to be connected to by said
counterpart.

I.e. any object created by this packages is always in one of two
complementary modes, called [term active] (the object initiates the
connection) and [term passive] (the object receives the connection).

[para]

Of the two objects in a connecting pair one has to be configured for
[term active] mode, and the other then has to be configured for
[term passive] mode. This establishes which of the two partners
connects to whom (the [term active] to the other), or, who is waiting
on whom (the [term passive] on the other).

Note that this is completely independent of the direction of any data
transmission using the connection after it has been established.

An active node can, after establishing the connection, either transmit
or receive data. Equivalently the passive node can do the same after
the waiting for it partner has ended.

[section API]

[list_begin definitions]

[call [cmd transfer::connect] \
	[arg object] \
	[opt [arg options]...]]

This command creates and configures a new connection [arg object]. The
fully qualified name of the object command is returned as the result
of the command.

[para]

The recognized options are listed below.

[list_begin options]

[opt_def -mode [arg mode]]

This option specifies the mode the object is in. It is optional and
defaults to [const active] mode. The two possible modes are:

[list_begin definitions]
[def [const active]]

In this mode the two options [option -host] and [option -port] are
relevant and specify the host and TCP port the object has to connect
to. The host is given by either name or IP address.

[def [const passive]]

In this mode the option [option -host] has no relevance and is ignored
should it be configured.

The only option the object needs is [option -port], and it specifies
the TCP port on which the listening socket is opened to await the
connection from the partner.

[list_end]

[opt_def -host [arg hostname-or-ipaddr]]

This option specifies the host to connect to in [term active] mode,
either by name or ip-address. An object configured for [term passive]
mode ignores this option.

[opt_def -port [arg int]]

For [term active] mode this option specifies the port the object is
expected to connect to. For [term passive] mode however it is the port
where the object creates the listening socket waiting for a
connection. It defaults to [const 0], which allows the OS to choose
the actual port to listen on.

[opt_def -encoding encodingname]
[opt_def -eofchar eofspec]
[opt_def -translation transspec]

These options are the same as are recognized by the builtin command
[cmd fconfigure]. They provide the configuration to be set for the
channel between the two partners after it has been established, but
before the callback is invoked (See method [method connect]).

[list_end]


[call [arg object] [method destroy]]

This method destroys the object. 

This is safe to do for an [term active] object when a connection has
been started, as the completion callback is synchronous.

For a [term passive] object currently waiting for its parter to
establish the connection however this is not safe and will cause
errors later on, when the connection setup completes and tries to
access the now missing data structures of the destroyed object.


[call [arg object] [method connect] [arg command]]

This method starts the connection setup per the configuration of the
object. When the connection is established the callback [arg command]
will be invoked with one additional argument, the channel handle of
the socket over which data can be transfered.

[para]

The detailed behaviour of the method depends on the configured
mode. For an [term active] object the connection setup is done
synchronously. I.e. the object will wait until the connection is
established. In that mode the method returns the empty string as its
result.

[para]

A [term passive] object however operates asynchronously. The method
will return immediately after a listener has been set up and the
connection will be established in the background. In that mode the
method returns the port number of the listening socket, for use by the
caller, like transfering this information to the counterpart so that
it may know where to connect to.

[para]

This is necessary as the object might have been configured for port
[const 0], allowing the OS to choose the actual port it will listen
on.

[para]

The listening port is closed immediately when the connection was
established by the partner, to keep the time interval small within
which a third party can connect to the port too. Even so it is
recommended to use additional measures in the protocol outside of the
connect and transfer object to ensure that a connection is not used
with an unidentified/unauthorized partner.

[list_end]


[section {BUGS, IDEAS, FEEDBACK}]

This document, and the package it describes, will undoubtedly contain
bugs and other problems.

Please report such in the category [emph transfer] of the
[uri {http://sourceforge.net/tracker/?group_id=12883} {Tcllib SF Trackers}].

Please also report any ideas for enhancements you may have for either
package and/or documentation.


[manpage_end]