Namespace Azos.Glue.Native
Classes
InProcBinding
Provides synchronous communication pattern based on in-memory message exchange without serialization. This binding is usable for interconnection between Azos-native components in the same app domain
InProcClientTransport
Provides client-side functionality for synchronous communication pattern based on in-memory message exchange without serialization
InProcServerTransport
Provides server-side functionality for synchronous communication pattern based on in-memory message exchange without serialization
MemChunk
Represents a stream/writable chunk of memory backed by an array buffer
MpxBinding
Provides asynchronous communicating pattern based on asynchronous virtual socket. The concrete socket may be based on OS-supported technology i.e. - IO completion ports on Windows
MpxClientSocket
Represents client-side asynchronous socket. This socket initiates a connection to MpxServerSocket
MpxClientTransport
Implements asynchronous MPX client transport for MpxBinding
MpxListener
Represents a server-side listener socket that accepts the calls
MpxServerSocket
Represents server-side asynchronous socket that clients connect to
MpxServerTransport
Implements asynchronous MPX server transport for MpxBinding
MpxSocket<TTransport>
Base for MpxSockets implementation. An MpxSocket represents an asynchronous bi-directional channel of communication that delivers binary/wire messages of flexible size. The socket is NOT THREAD SAFE for calling Send() from parallel threads. Send() is done synchronously on the calling thread, i.e. the sender waits until the data is written into the OS socket buff. Receive is invoked by internal/system/io thread asynchronously and should not block for long (seconds)
MpxSocketFactory
Defines factory abstraction that creates socket per particular technology
MpxWinClientSocket
Implements a MPX client socket using Windows IO completion ports for receive
MpxWinListener
Implements a MPX socket listener that accepts connections into MpxWinServerSocket
MpxWinServerSocket
Implements a MPX server socket using Windows IO completion ports for receive
MpxWinSocketFactory
Factory that makes MpxWin sockets based on Windows-IO completion ports
SyncBinding
Provides synchronous communication pattern based on TCP blocking sockets and Slim serializer for maximum serialization performance and lowest latency. This binding is usable for interconnection between Azos-native components on LANs (i.e. server clusters) in scenarios when low latency is more important than total call invocation throughput
SyncClientTransport
Provides client-side functionality for synchronous communication pattern based on TCP blocking sockets and Slim serializer for maximum serialization performance and lowest latency. The SyncBinding is usable for interconnection between Azos-native components on LANs (i.e. server clusters) in scenarios when low latency is more important than total call invocation throughput
SyncServerTransport
Provides server-side functionality for synchronous communication pattern based on TCP blocking sockets and Slim serializer for maximum serialization performance and lowest latency. The SyncBinding is usable for interconnection between Azos-native components on LANs (i.e. server clusters) in scenarios when low latency is more important than total call invocation throughput. SyncServerTransport uses dedicated thread for request processing and is not scalable beyond a few hundred connections by design, however it provides low latency benefit
Structs
ClientSite
Represents a client call site identifier which gets generated on client and sent to server upon handshake. This struct identifies the calling client by supplying machine/host name and calling application instance ID
WireFrame
This struct defines a frame transmitted as a part of WireMsg which can be used for transport or session management needs
WireMsg
Represents a message that is transmitted over the wire:
Interfaces
IMpxTransport
Enums
FrameType
Type of transport frame message
Delegates
MpxSocketReceiveAction<TTransport>
Delivers wire msg from another side. DO NOT use WireMsg beyound the implementation of this delegate, if needed make a copy of msg.Data as the memory will be freed after this call returns