Vortex Types: Types definitions used across Vortex Library.

MAX_BUFFER_SIZE MAX_CHANNEL_NO MAX_CHANNELS_NO MAX_MESSAGE_NO MAX_MSG_NO MAX_SEQ_MOD MAX_SEQ_NO MAX_SEQUENCE_NO MIME_CONTENT_DESCRIPTION MIME_CONTENT_ID MIME_CONTENT_TRANSFER_ENCODING MIME_CONTENT_TYPE MIME_VERSION QUEUE_PRIORITY_PUSH QUEUE_PUSH VortexAsyncQueue VortexChannel VortexChannelPool VortexCond VortexConnection VortexCtx VortexDebugLevel VortexEncoding VortexFrame VortexFrameType VortexHash VortexIoWaitingFor VortexIoWaitingType VortexMimeHeader VortexMutex VortexPeerRole VortexQueue VortexStatus VortexThread VortexThreadConf VortexThreadFunc VortexTunnelItem VortexTunnelSettings WaitReplyData

enum VortexIoWaitingType Enumeration type that allows to use the waiting mechanism to be used by the core library to perform wait on changes on sockets handled. Enumerator: VORTEX_IO_WAIT_SELECT  Allows to configure the select(2) system call based mechanism. It is known to be available on any platform, however it has some limitations while handling big set of sockets, and it is limited to a maximum number of sockets, which is configured at the compilation process. Its main disadvantage it that it can't handle more connections than the number provided at the compilation process. See <vortex.h> file, variable FD_SETSIZE and VORTEX_FD_SETSIZE. VORTEX_IO_WAIT_POLL  Allows to configure the poll(2) system call based mechanism. It is also a widely available mechanism on POSIX envirionments, but not on Microsoft Windows. It doesn't have some limitations found on select(2) call, but it is known to not scale very well handling big socket sets as happens with select(2) (VORTEX_IO_WAIT_SELECT). This mechanism solves the runtime limitation that provides select(2), making it possible to handle any number of connections without providing any previous knowledge during the compilation process. Several third party tests shows it performs badly while handling many connections compared to (VORTEX_IO_WAIT_EPOLL) epoll(2). However, reports showing that results, handles over 50.000 connections at the same time (up to 400.000!). In many cases this is not going your production environment. At the same time, many reports (and our test results) shows that select(2), poll(2) and epoll(2) performs the same while handling up to 10.000 connections at the same time. VORTEX_IO_WAIT_EPOLL  Allows to configure the epoll(2) system call based mechanism. It is a mechanism available on GNU/Linux starting from kernel 2.6. It is supposed to be a better implementation than poll(2) and select(2) due the way notifications are done. It is currently selected by default if your kernel support it. It has the advantage that performs very well with little set of connections (0-10.000) like (VORTEX_IO_WAIT_POLL) poll(2) and (VORTEX_IO_WAIT_SELECT) select(2), but scaling much better when going to up heavy set of connections (50.000-400.000). It has also the advantage to not require defining a maximum socket number to be handled at the compilation process.