Vortex Library has some interesting features you may find as key point to chose it as your project to support your data transport layer.
- It has a consistent API exposed by a strong function module naming. Vortex Library doesn't expose to your code any detail that may compromise your code in the future due to internal Vortex changes or future releases. This is really important to us: backward compatibility will be ensured and no change to the internal Vortex Library implementation will break your code. This is also very important while thinking about building bindings for library. Its API is already prepared because all interactions between user space code and the library is done through functions and opaque types.
- It has been designed keeping in mind security: buffer overflows, DOS attacks (socket handling is done using non-blocking mode), internal or external frame fragment attack or channel starvation due to flooding attacks. Actually, It is been used by the Af-Arch project (http://fact.aspl.es) which requires transferring really large chunks of data by several channels over several connection for several clients at the same time.
- It supports both asynchronous and synchronous programing models while sending and receiving data. This means you can program a handler to be executed on frame receive event (and keep on doing other things) or write code that gets blocked until a specific frame is received. This also means you are not required to use handler or event notifications when you just want to keep on waiting for an specific frame to be received. Of course, while programing Graphical User Interfaces the asynchronous model will allow you to get the better performance avoiding the my-application-gets-blank effect on requests ;-)
- Operations such as open a connection, create a channel, close a channel, activate TLS profile, negotiate authentication through SASL profiles, can be made in an asynchronous way avoiding you getting blocked until these operation are completed. Of course synchronous model is also provided. If you want a library that allows you to start a connection creation process, keep on doing other things and be notified only when the connection has been created or denied, the Vortex Library is for you.
- It support a flexible schema to dispatch received frames allowing you to tweak different levels of handlers to be executed, including a wait reply method, which disables the handlers installed. You can check more about this issue on the following section.
- Vortex Library comes with a tool called vortex-client which allows to make operations against BEEP-enabled peers. This tool can help you on debugging your applications not only running Vortex Library but also other BEEP enabled implementations. It has support to:
- Create connections, create channels, check status for both: sequence numbers, next expected sequence numbers, reply numbers, next expected reply number, message number status, profiles supported by remote side, etc...
- It allows to send message according to actual channel status or using the frame generator to create frames with user provided data.
- It allows to generate and send close messages and start message allowing you to check how your code works.
- Vortex Library implements the channel pool concept. This allows you to create a pool of channels ready to be used to send data. The library will handle which channel to use from the pool when the next channel ready is required, avoiding get blocked due to possible previous operations over that channel. It also has the ability to automatically increase the channel pool and negotiate for you the channel creation when the next channel ready is requested but no one is available.
- You can close channels and connections (including that one that is receiving the frame) inside the frame receive handler you may define for both second and first level.
- You can reply any message you may want (including the one which have caused to be invoke the frame receive handler) or to send any new message inside the frame receive handler you may define.
- The close channel and close connection protocol is fully implemented according to all circumstances that may happen described at RFC3080 standard. This means your code will not be required to implement a close notification between peers in other to avoid sending message that may cause the transport layer to break. You can actually close any channel (including the complete session) without worry about if remote peer is done.
- If you are planning to use XML as your encapsulation format for some of your profiles, Vortex Library comes with its own XML 1.0 implementation, called Axl (http://xml.aspl.es), which provides all required functionality to parse and produce XML documents and validate them. It is extremely memory efficient and fast. Check out the memory report found that the Axl home page (http://xml.aspl.es).
- Vortex Library includes a complete XML-RPC over BEEP support, with a Raw invocation API, and a protocol compiler, xml-rpc-gen which allows to produce server and client components really fast. See the XML-RPC over BEEP manual for more details.
- Vortex Library includes a complete TUNNEL profile support (RFC3620), allowing to "proxy" protocols you may design on top of Vortex. See TUNNEL profile manual.
- The Vortex Library is well documented (ok, this shouldn't be a feature ;-), with examples of code, not only about how to use Vortex Library but also how it has been programed internally.
- Vortex Library is released under Lesser General Public License allowing to create open source projects but also proprietary ones. See this section for more information about license topic.
