I use Net.Sockets.Socket class to write a TCP server. Since TCP operates on streams, one needs an approach to seperate messages from each other. (For details, see the Message Framing post of Stephen Cleary in his blog here.)
What I want to achieve is writing a TCP server class with the support for custom message framing protocols. An example initialization of this class is here:
var receiveDelimiter = Encoding.UTF8.GetBytes("[END]");
var sendDelimiter = Encoding.UTF8.GetBytes("\r\n");
var protocol = new DelimiterFramingProtocol(receiveDelimiter, sendDelimiter);
var server = new Server(protocol);
server.Start(port);
The protocol should be derived from the abstract class MessageFramingProtocol and the server should be able to use it to seperate messages. In the example above, the server should only fire its DataReceived event if the delimiter (which is "[END]") is received and the arguments of DataReceived should only have the part of the message that is before the delimiter. If there are more bytes received after the delimiter, the server should store them and fire DataReceived only when the delimiter is received again. Server also should send the sendDelimiter after every message that it sends.
What I need is not this whole server class or any of the protocol classes. What I need is a template, a design advice. Assuming I have a property of type FramingProtocol called Protocol in the server class, how can I use it in receiving and sending operations in the Server class? What abstract methods / properties it should have to provide the flexibility that you see above? I should be able to write custom protocol classes that derive from FramingProtocol. They may use delimiters, length-prefixing, both of them or other, custom approaches to seperate messages.
I wouldn't go with only one Protocol instance that is passed to the server - it will need lots of them. Provide the server with a factory class that either creates new Protocol instances or depools them from a pool created and filled at startup.
What I usually do is something like this:
RX:
Provide an 'int Protocol::addBytes(char *data,int len)' function. Fed with the address and length of raw rx data, the function returns either -1, (means that it has consumed all the raw data without fully assembling a protocol unit), or a positive integer that is the index of data consumed at the point it assembled a valid PDU. If the instance manages to assemble a PDU, it can be further processed, (eg. fired into a 'DataReceived(Protocol *thisPDU)' event and a new Protocol instance created, (or depooled), and loaded up with the remaining raw data.
TX:
Provide, (quite possibly overloaded), 'bool Protocol::loadFrom(SomeDataClass * outData, OutStreamClass *outStream)' methods that can load data from whatever source into internal member vars so that a complete set of data exists to generate a serialized PDU, (and return false, or raise an exception if there is some issue - eg. provided data fails sanity-check). If no error is detected, the instance drives the serialized data out of the passed 'outStream' stream/socket/buffer+len.
Related
What is the difference? As I understood the Tell (object, IActorRef) sends original sender. But why not to use just the Forward method?
Thank you
You can think of actorRef.Tell(msg) as a shortcut for actorRef.Tell(msg, Context.Self), while actorRef.Forward(msg) keeps original message Sender. This also mean, that you need an active actor context in the background to have any meaningful Sender defined.
Using Tell(object, IActorRef) allows you to set Sender to any actor ref you like, including things like impersonation as another actor or ActorRefs.NoSender, which may be used i.e. to reduce size of a payload send over the wire, as the message sender won't be serialized.
In some of remote scenarios, if you don't expect to send an answer to a Sender, using actorRef.Tell(msg, ActorRefs.NoSender) may bring nice performance benefit.
Why? IActorRef is serialized as URI string (example: akka.tcp://system-name#localhost:9001/user/parent/child). When you're sending small messages i.e. stock price ticks or a game character position changes, this may mean that the most expensive part of your payload is actually a Sender.
Deserializing IActorRef also takes some extra time, because actor provider needs to resolve correct message transport for it.
For those reasons, if you don't need the Sender, using ActorRefs.NoSender may be a valid option.
I wish to send packets to sync properties of constantly changing game objects in a game. I've sent notifications of when a property changes on the server side to a EntitySync object that is in charge of sending out updates for the client to consume.
Right now, I'm pre-fixing the property string name. This is a lot of overhead for when you're sending a lot of updates (position, HP, angle). I'd like for a semi-unique way to idneity these packets.
I thought about attributes (reflection... slow?), using a suffix on the end and sending that as an ID (Position_A, HP_A) but I'm at a loss of a clean way to identify these properties quickly with a low foot print. It should consume as few bytes as possible.
Ideas?
Expanding on Charlie's explanation,
The protobuf-net library made by Marc Gravell is exactly what you are looking for in terms of serialization. To clarify, this is Marc Gravell's library, not Googles. It uses Google's protocol buffer encoding. It is one of the smallest footprint serializes out there, in fact it will likely generate smaller packets than you manually serializing it will ( How default Unity3D handles networking, yuck ).
As for speed, Marc uses some very clever trickery (Namely HyperDescriptors) http://www.codeproject.com/Articles/18450/HyperDescriptor-Accelerated-dynamic-property-acces
to all but remove the overhead of run time reflection.
Food for thought on the network abstraction; take a look at Rx http://msdn.microsoft.com/en-us/data/gg577609.aspx Event streams are the most elegant way I have dealt with networking and multithreaded intra-subsystem communication to date:
// Sending an object:
m_eventStream.Push(objectInstance);
// 'handling' an object when it arrives:
m_eventStream.Of(typeof(MyClass))
.Subscribe ( obj =>
{
MyClass thisInstance = (MyClass) obj;
// Code here will be run when a packet arrives and is deserialized
});
It sounds like you're trying to serialize your objects for sending over a network. I agree it's not efficient to send the full property name over the wire; this consumes way more bytes than you need.
Why not use a really fantastic library that Google invented just for this purpose.
This is the .NET port: http://code.google.com/p/protobuf-net/
In a nutshell, you define the messages you want to send such that each property has a unique id to make sending the properties more efficient:
SomeProperty = 12345
Then it just sends the id of the property and its value. It also optimizes the way it sends the values, so it might use only 1, 2, 3 bytes etc depending on how large the value is. Very clever, really.
I run an algorithm that receives out-of-process messages of different types. The incoming messages are actually byte arrays and each byte array is pre-pend by a byte array flag indicating the message type. I like to understand whether it is possible to setup an IPropagator<byte[], byte[]> that processes the incoming byte arrays, interprets the byte array flags and then streams the byte array to a specific corresponding linked ActionBlock.
For example lets say I have 2 different message types and I have 2 different corresponding ActionBlocks that should only receive messages that match with the intended message type they are supposed to receive. I believe if I just link the IPropagatorBlock to both Actionblocks that both ActionBlocks will receive the same message? How can I correctly allocate each message depending on its flag (do not worry about the flag, the identification is trivial, lets assume I know at any time to which ActionBlock IPropgatorBlock wants to stream the message)? I am struggling with correctly setting up the data flow structure. I would love to be able to link the data blocks directly to each other rather than having to Post(). Is that possible?
Any help in that regards is much appreciated.
This depends on the IPropagatorBlock that you're using. If it's a custom one, you can do anything, including for example recognizing which target block to use based on the order they're linked (or something more reliable).
But assuming the block is actually a normal TransformBlock (or something like that), I think the best option is to use the overload of LinkTo() that takes a predicate, and adding the flag to the output type (which means changing the type of the block to IPropagatorBlock<byte[], Tuple<FlagType, byte[]>>, or a custom type instead of the Tuple). If you do this, then you can be sure that the target will receive the message only if the predicate for that target matches the message.
Also, what happens if you link one source block to more target blocks depends on the source block. In most cases, it sends each message to exactly one target: it first tries the first target, and only tries the second one if the first one declines or postpones the message. The exception to this rule is BroadcastBlock (and the similar WriteOnceBlock), that always tries to send each message to all targets. Again, a custom block can behave any way it wants.
I'm currently assigned to a task to develop a software module to communicate with a stepper motor controller. The project is written in C#, I have a C++ dll to communicate with the controller. The communication runs via the Serial port. I'm planning to write the whole piece in C# by importing the necessary methods by DllImport. The key method looks something like :
ComSendReceive(pHandle, bufferIn,sizeBufferIn,bufferOut,ref bufferOut)
There are several types of messages :
You send message and expect confirmation (not the same for every message, sometimes it's OK, sometimes it's COMPLETE etc..
You send message and receive message - you can receive an error or data (for instance GET_CONTROLLER_ID)
Several other types
Of course I need to control the communication for time-outs.
My question is: Is there any "design pattern" to use for that kind of problem? I'm sure this is quite a common problem many developers have solved already.
To contribute a little - I dealt with similar problem in my last job and I solved it this way :
I had a class to communicate with the Com port and a class AT_message with bunch of overloaded constructors :
class AT_Message
{
public bool DoResponseCheck;
public string ExpectedResponse;
public AT_COMMAND command;
public string data;
public bool AddCarriageReturn;
...
//Plenty of ctors
}
class UnfriendlyInterface
{
Response SendMessage(AT_Message msg)
{
//Communicates directly with C++ dll, send message, check timeouts etc....
}
}
And I had a class the main application was communicating with, it had human friendly methods like
class FriendlyInterface
{
bool AutodetectPortAndOpenComm();
Result AnalyzeSignal(byte[] buffer)
{
Response response = UnfriendlyInterface.SendMessage(new Message(AT_Command.PrepareForSignal, (doResponseCheck)true, ExpectedResponse.Ok,Timeout.short);
Response response = UnfriendlyInterface.SendMessage(new Message(buffer,(doResponseCheck)false,Timeout.long);
//.... Other steps
}
//... other methods
}
Since last time I was really in a big hurry, I implemented first solution that came to my mind. But is there a way to do it better? Now the device I'm communicate with is more complex than the previous one so if there's a way how to do it better, I'd like to do it that way.
This seems like a textbook facade pattern. The answer to all of this is to encapsulate your variation. For example, try to create a generic interface for commands that give an acknowledgement, and write client code to use that interface. Then concrete types can decide how to interpret various acknowledgements into a uniform signal (Ok = Complete = Good, or whatever)
Here's a good article on the facade pattern. Also see the wikipedia article.
When writing a custom channel how can I get the name of the service method that will be called.
For example, if the operation contract looks like the following, how can I know if Method1 or Method2 is being called?
[OperationContract]
void Method1( int data );
[OperationContract]
void Method2( int data );
The channel itself doesn't perform any major function on the Message, it just adds some extra data. What I am looking for is to customize the extra data added in the channel depending on the method being called (or more specifically if it is decorated with something).
If you are creating a transport channel, then that's completely up to you. The responsibility is on you to take the incoming bytes and translate it to a message which will then be pushed down the channel stack.
If you are creating a protocol channel, you can just access the OperationContext (it should be set by that time) and check the IncomingMessageHeaders property and get the action header. This is what is used to map to the OperationContract.
What exactly are you trying to do here, and at what point are you trying to do it? What kind of channel are you trying to create exactly? Your question doesn't have enough information to really give an answer.