IP*Works! Visual Basic Ed.

          List of Controls

Main goal in designing IPPort was ease of use. The control has a minimum of properties and five events: Connected, DataIn, Disconnected, ReadyToSend, and Error. The events are relatively self-explanatory.

The connection is attempted by setting the Connected property to True, and then waiting for the Connected event. The destination is defined by setting RemoteHost and RemotePort. Data is sent by assigning the data string to the DataToSend property.

To disconnect, you just set the Connected property to False. The Linger property controls how the connection is terminated.

The operation of the control is almost completely asynchronous. All the calls except the ones that deal with domain name resolution, operate through Windows messages (no blocking calls). The gain in performance is considerable when compared to using blocking calls.

IPDaemon is the server complement of IPPort (which is used to create client applications). They share a common design philosophy and interface. We expect you will find IPDaemon as easy to use as IPPort.

Each instance of IPDaemon can handle close to 1000 simultaneous incoming connections. These connections are identified by a ConnectionID (a number between 1 and 1000). Most of IPDaemon's properties are array properties indexed by ConnectionID. IPDaemon's events also have ConnectionID as a parameter to identify the connection they relate to.

Our main goal in designing IPDaemon was to make it easy to use without sacrificing performance. The control has a minimum of properties, and six events: ConnectionRequest, Connected, DataIn, Disconnected, ReadyToSend, and Error.

IPDaemon can start to listen on a port by setting the Listening to True. When a remote host asks for a connection, the ConnectionRequest event is fired. At that point, the connection can either be accepted or rejected. If the connection is accepted, a ConnectionID is assigned, and communication can start. From this point on, the operation is very similar to IPPort. Data is sent by assigning the data string to the DataToSend property. The address and port of the incoming connection can be found by querying the RemoteHost and RemotePort properties.

The SMTP control implements a standard SMTP client as specified in RFC 821. It has a simple plug-and-play interface. It contains a number of properties like To, Subject, From, Cc, BCc, etc. that map directly to the internet mail message headers with the same name (RFC 822). The message text is set in MessageText and/or AttachedFile. Messages are sent by setting the Action property to 'Send Message'.

The control supports message delivery to multiple recipients through the To, Cc, and BCc properties. Simply specify the destination email addresses separated by commas.

The interface of the control is open-ended. New features, including MIME attachments can be supported by using the OtherHeaders property.

A number of events provide feedback during the operation of the control. The Transfer event is fired during message delivery to show the number of bytes delivered. The PITrail event traces the commands that are sent to the server and the respective replies.

The POP control implements a standard internet post office (POP3) client as specified in RFC 1725.

The control is driven by a few key properties and the Action property. To connect to a MailServer first set the appropriate User and Password and then connect by setting Action to 'Connect'. Upon successful connection to the MailServer, the number of waiting messages is shown by the MessageCount property. A message is selected by setting the MessageNumber property to a number between 1 and MessageCount (inclusive). Then, message text and/or headers are received by setting Action to the appropriate value.

The message text is received through the Transfer event, whereas the message headers are received through the Header event. StartTransfer and EndTransfer are fired at the beginning and end of message transmission. The PITrail event provides a trace of the interaction between the client and server (excluding message transfers).

The interface of the control is similar to the interface of IPPort, only much simpler. The control is activated/deactivated through the Active property. This property enables or disables sends or receives. The data can be sent in the same way as IPPort, using the DataToSend property. The destination is specified using the RemoteHost and RemotePort properties. Inbound data is received through the DataIn event.

If the UseConnection property is set to True, then a local association is created with the remote host. Otherwise, the control can receive datagrams (packets) from any host, and send datagrams to any host. Packets can be broadcasted on the local net by setting the destination (RemoteHost) to 255.255.255.255.

The operation of the control is almost completely asynchronous. All calls, except the ones that deal with domain name resolution, operate through Windows messages (no blocking calls). The gain in performance is considerable when compared to using blocking calls.

The MCast control is very similar to UDPPort, except for some additional properties that provide support for multicast datagrams. To send datagrams to a multicast group, simply assign the address of the group to RemoteHost. To receive datagrams from one or more groups, assign the group addresses to MulticastGroup one by one (after the control is activated. TimeToLive allows to specify how many subnets a packet should be allowed to receive. ReceiveInterface and SendInterface allow you to select the network interface for multicast operations.

The control is activated/deactivated through the Active property. This property enables or disables sends or receives. The data can be sent in the same way as UDPPort, by using the DataToSend property. The destination is specified using the RemoteHost and RemotePort properties. Inbound data is received through the DataIn event.

The IPInfo control operates asynchronously. Requests are posted to the control by setting a property like HostName, HostAddress, ServiceName, ServicePort and then waiting for the RequestComplete. The RequestID property identifies the request.

Up to 100 simultaneous requests can be queued at any moment. PendingRequests shows the number of pending requests, and may also be used to adjust the size of the queue (by dumping a number of the pending requests).

The NNTP control implements a standard Usenet news reader as specified in RFC 977. It can be used to browse Usenet news groups and read and post articles.

The control operates mainly by setting action codes to the Action property. The CurrentGroup property sets the current newsgroup. From then on, news articles from that group can be read by setting the article number in CurrentArticle and then setting the appropriate Action code. Properties like ArticleCount, FirstArticle, LastArticle provide information about the current state.

The headers and text of the articles are received respectively through the Header and Transfer events. The GroupOverview event returns information about a range of articles (OverviewRange) in CurrentGroup, and the GroupList event is used when listing newsgroup names. The PITrail event provides a trace of the interaction with the server.

The control supports posting of articles through the ArticleText and AttachedFile properties. The article text is specified in one or both of the above, and then the appropriate Action code is sent. Article headers are given in a series of properties like From, Subject, Organization, etc. that map directly to the article header with the same name.

.

NetCode's operation is controlled by assigning a value to the Action property. The encoding format is specified by the Format property. The binary data, or the name of the file containing binary data, is specified by the DecodedData property and the encoded data or filename is specified by the EncodedData property. The FileName property may be used to override the default file names or to specify a directory during uuencoding. After uudecoding, the FileName property contains the fully specified file name of the decoded file.

.

The Telnet control provides a simple interface to Telnet communications as specified by RFC 854. It allows sending of Telnet command codes to remote Telnet servers and it scans the input data for Telnet commands. Appropriate events are fired for received commands.

The connection interface is very similar to that of IPPort. The same properties and events are used for sending and receiving normal data, and the same property set is used for setting properties of the connection. The Telnet control adds a number of properties like Command, DoOption, etc. which allow sending of Telnet commands to the other end. The respective events (Command, Do, etc.) are fired when the corresponding Telnet commands are received.

The Rshell control allows remote execution of commands on UNIX hosts, or any other system with the rshell interface. Using the control is very simple. The destination is specified by the RemoteHost property, the login information is given by the LocalUser and RemoteUser properties, and the command to execute by the Command property. Further input can be supplied to the command by assigning data to the Stdin property.

The output of the command is returned through the Stdout event. If an error happens on the protocol level, the error message can be found in the ErrorMessage property. Errors during command execution (the stderr stream) are given by the Stderr event.

To be able to successfully use the control, the remote host must be set up to allow execution of commands via rshell from the machine the control runs on.

.

The Rexec control allows remote execution of commands on UNIX hosts, or any other system with the rexec interface. Using the control is very simple. The destination is specified by the RemoteHost property, the login information is given by the RemoteUser and RemotePassword properties, and the command to execute by the Command property. Further input can be supplied to the command by assigning data to the Stdin property.

The output of the command is returned through the Stdout event. If an error happens on the protocol level, the error message can be found in the ErrorMessage property. Errors during command execution (the stderr stream) are given by the Stderr event.

To be able to successfully use the control, the remote host must be set up to allow execution of commands via rexec from the machine the control runs on.

.

The interface of the control is similar to the interface of IPPort, only much simpler. The control is activated/deactivated by using the Active property. This property enables or disables sends or receives. Data can be sent in the same way as IPPort, using the DataToSend. The destination is specified using the RemoteHost property. Inbound data is received through the DataIn event. The control automatically creates an ICMP header containing MessageType, MessageSubType, and a checksum for the message.

If the UseConnection is set to True, then a local association is created with the remote host. Otherwise, the control can receive datagrams (packets) from any host, and send datagrams to any host. Packets can be broadcasted on the local net by setting the destination to 255.255.255.255.

The operation of the control is almost completely asynchronous. All the calls, except the ones that deal with domain name resolution, operate through Windows messages (no blocking calls). The gain in performance is considerable when compared to using blocking calls.

.

The Action property controls the operation. The user can either directly provide a PhoneNumber User, Password, and eventually Domain and CallbackNumber or get those entries from PhonebookEntry of Phonebook. The calls are blocking but progress information is given through the Status event and Windows messages will come during connect or disconnect actions.

The user can get information on the phonebook entries and connections by assigning the respective command to Action property and get the information through the ConnectedEntry and PhonebookEntry events.

.