The ActiveX component enables peer-to-peer connections and allows labeling of peers as either Listener or Initiator. It includes profiles for tasks such as testing, ROT13 encryption, ZIP tuning, etc.
ActiveX component is a peer-to-peer connection that allows efficient labeling of each peer as either a Listener(Server) or Initiator(Client). The component includes several profiles such as SINK/ECHO profiles for testing, ROT13 profile that will grab message data, ZIP Tuning profile that will compress contents of messages on the fly, SYSLOG Raw and Cooked profiles for transmitting (and receiving) syslog messages.
BEEP protocol is a generic application protocol designed for connection-oriented, asynchronous interactions. It enables independent and simultaneous exchanges within the context of a single application user-identity. It supports both textual and binary messages. BEEP peers communicate with MESSAGES over predefined CHANNELS. Messages are generated by application-defined PROFILES, which defines parsing to provide the necessary information before a message is sent, and once the message is received by the peer.
MESSAGES are initiated by an application and prepared by the defined Profile. The corresponding Profile awaits on the other side to parse the message and provide only the necessary information. All exchanges occur in the context of a channel, which is a binding to a well-defined aspect of the application, such as transport security, user authentication, or data exchange. Each channel has an associated "profile" that defines the syntax and semantics of exchanged messages. Implicit in the operation of BEEP is the notion of channel management. Except for a few profiles defined internally in wodBeep, a user can define their profiles for data exchange, tuning parameters, etc.
A BEEP session is mapped onto an underlying transport service, such as a single TCP connection, UDP, or any higher level two-way transport service like SMTP architecture. wodBeep implements TCP transport for use, but users can implement any other transport service easily by implementing the IBeepTransport interface.
BEEP protocol is a generic application protocol designed for connection-oriented, asynchronous interactions. It enables independent and simultaneous exchanges within the context of a single application user-identity. It supports both textual and binary messages. BEEP peers communicate with MESSAGES over predefined CHANNELS. Messages are generated by application-defined PROFILES, which defines parsing to provide the necessary information before a message is sent, and once the message is received by the peer.
MESSAGES are initiated by an application and prepared by the defined Profile. The corresponding Profile awaits on the other side to parse the message and provide only the necessary information. All exchanges occur in the context of a channel, which is a binding to a well-defined aspect of the application, such as transport security, user authentication, or data exchange. Each channel has an associated "profile" that defines the syntax and semantics of exchanged messages. Implicit in the operation of BEEP is the notion of channel management. Except for a few profiles defined internally in wodBeep, a user can define their profiles for data exchange, tuning parameters, etc.
A BEEP session is mapped onto an underlying transport service, such as a single TCP connection, UDP, or any higher level two-way transport service like SMTP architecture. wodBeep implements TCP transport for use, but users can implement any other transport service easily by implementing the IBeepTransport interface.
What's New
Version 1.0.0.0: N/A