291
TIDE and Tibbo BASIC User Manual
©2000-2008 Tibbo Technology Inc.
Just like with connection establishment, you can monitor the progress of
connection termination- see
.
Notice, that depending on the socket state at the moment of sock.close
method invocation, the socket may need to resort to a simple
connection closing option- reset or discard. Similarly, when you use the
sock.reset, it may sometimes result in discard. For more information
read the
,
, and
topics.
Actively closing UDP connections
For UDP, no matter what method you use to close the "connection", result will still
be as if the sock.discard was invoked. This is because in reality there is no such
thing as a proper UDP connection termination so simply "forgetting" about the
connection is the only option the socket has.
Do not forget: connection handling is fully asynchronous!
Keep in mind that the sock object handles communications asynchronously. When
the VM executes the
,
) method it does
not mean that the connection is done with by the time the VM gets to the next
program statement. Executing these methods merely instructs the master process
to terminate the connection. Connection termination can take some time and your
application doesn't have to wait for that to complete.
topic explains how to find out actual connection status at any time (see
and
read-only properties).
Asynchronous nature of the sock object has some interesting
implications.
More On the Socket's Asynchronous Nature
topic
contains important information on the subject, so make sure you read
it!
Socket re-use after connection closing
When the socket connection terminates, the socket is ready to accept another
incoming connection or establish a new outgoing connection (if so configured) --
with one little caveat! There is a special built-in mechanism that ensures that your
application has a chance to react after the previous connection terminates and
before the next one is established.
For example, you might need to clean some buffers before each new incoming TCP
connection. Naturally, you want this to happen before the new connection is
actually accepted.
Typically, your program achieves this by executing code placed in the
event handler (this event is explained in
topic). The socket will not be able to engage in the new connection until
the on_sock_event has a chance to execute. There is an interesting example on
this in the
More On the Socket's Asynchronous Nature
topic.
Connection timeouts
provides a way to automatically terminate a connection
across which no data was exchanged for a predefined period of time. For TCP,
reset (abort) is used, while UDP "connections" are simply discarded. Connection
292
328
348
331
328
348
331
292
355
358
294
343
292
294
330