[![Join the chat at https://gitter.im/akkadotnet/Wire](https://badges.gitter.im/akkadotnet/Wire.svg)](https://gitter.im/akkadotnet/Wire?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
In message based systems, it is common to receive different types of messages and apply pattern matching over those messages.
If the messages does not carry over all the relevant type information to the receiveing side, the message might no longer match exactly what your system expect.
Consilder the following case:
```csharp
public class Envelope
{
//untyped property
public object Payload {get;set;}
//other properties..
...
}
...
var envelope = new Envelope { Payload = (float)1.2 };
```
If you for example are using a Json based serializer, it is very likely that the value `1.2` will be deserialized as a `double` as Json has no way to describe the type of the decimal value.
While if you use some sort of binary serializer like Google Protobuf, all messages needs to be designed with a strict contract up front.
Wire solves this by encoding a manifest for each value - a single byte prefix for primitive values, and fully qualified assembly names for complex types.
This is essential for frameworks like Akka.NET where we need to be able to resolve live Actor References in the deserializing system.
## Version Tolerance
Wire has been designed to work in multiple modes in terms of version tolerance vs. performance.
1. Pre Register Types, when using "Pre registered types", Wire will only emit a type ID in the output stream.
This results in the best performance, but is also fragile if different clients have different versions of the contract types.
2. Non Versioned, this is largely the same as the above, but the serializer does not need to know about your types up front. it will embed the fully qualified typename
in the outputstream. this results in a larger payload and some performance overhead.
3. Versioned, in this mode, Wire will emit both type names and field information in the output stream.
This allows systems to have slightly different versions of the contract types where some fields may have been added or removed.
Wire has been designed as a wire format, point to point for soft realtime scenarios.
If you need a format that is durable for persistence over time.
e.g. EventSourcing or for message queues, then Protobuf or MS Bond is probably a better choise as those formats have been designed for true versiom tolerance.
## Performance
Wire has been designed with a performance first mindset.
It is not _the_ most important aspect of Wire, Surrogates and polymorphism is more critical for what we want to solve.
But even with it's rich featureset, Wire performs extremely well.