-
Notifications
You must be signed in to change notification settings - Fork 39
History of ServiceWire
ServiceWire started out as DuoVia.Net in April 2013. Development continued under that name until January 2014 when it was renamed ServiceWire.
The original notion of ServiceWire was inspired by the work of Frank Thomsen published in 2008 on Codeplex under the name RemotingLite and released under the BSD license. While only a small amount of code taken from that project remains in ServiceWire, the essence of the intent of the code remains. RemotingLite was designed only for TCP/IP communication and supported a Mono build.
ServiceWire extended and improved RemotingLite in many ways. A few of these are:
- Named Pipes (not supported on platforms running Mono, so Mono support was eliminated)
- Injectable logging and performance statistics instrumentation
- Interception
- Enhanced support for ByRef (out and ref) parameters
- Multiple performance improvements to:
- expanded native types and arrays of native types serialization
- completely new async sockets handling for faster, more stable hosting over TCP/IP
- use of Task Parallel Library (TPL) to improve threading performance
- extensive use of Concurrent collections to reduce locking and potential race conditions
- critical dynamic proxy improvements
- eliminates costly use of StackFrame
- reduces use of reflection
- caches dynamically generated proxy assemblies to eliminate memory leak
While the author's employer does not officially endorse or support ServiceWire, it has been used by that employer, an organization of over 800 employees with multiple locations around the world and many thousands of servers and petabytes of data in use. The teams using ServiceWire have several use cases that involve processing billions of records within and across multiple servers. Users have reported improved performance between their processes and have run these processes for days on end reliably and without any serious problems. The author thanks these teams for their participation in testing ServiceWire under heavy load scenarios, helping to discover one or two weaknesses that were quickly resolved. This usage has proven that ServiceWire is ready for prime time.