Non-prerelease version - at least of the NuGet package

[burningice2866]

Will there ever be a non-prerelease version, at least of the NuGet package? Its a pain to reference a released project which then depends on WampSharp since the NuGet package manager just throws an error. Yes, you can enable the -IncludePrerelease switch but that opens up for prerelease versions of all kinds of packages, unless you then install the WampSharp packages individually first using the switch, and then install the main package you wanted in the first place without the -IncludePrerelease switch.

[darkl]

Dear community,

Please comment here if you think that WampSharp is stable enough for labeling it as a non-prerelease version.

Please add some brief explanations to justify that.
If you are using WampSharp in production, please describe briefly what are you doing with WampSharp, also please answer the following questions:

• What platform are you targeting (what operating system + what framework, including version)?
• Are you using WampSharp as a router or a client?
• If you are using WampSharp as a router, please specify what transport are using. If your router is hosted on IIS or some other special setting, please specify that too.
• If you are using WampSharp as a client, please specify which router are you connecting to.

Please mention anything that you think that can be relevant for this decision.
Elad

[esso23]

Hi Elad,

I think WampSharp is definitely ready for release. We've been using it in production for ~2 years now and are very satisfied with it.

• Targeted platforms: Windows Server 2012/2008
• We're using both router and client
• Our router runs as a standard windows service and we're using WebSocket/MsgPack transport, we are using WampSharp and AutobahnJS clients to connect and we have roughly 5 clients connected at the same time (10 at most)
• We are connecting to WampSharp router exclusively
• Our major deployment of WampSharp has thousands of value updates per second (from main data source client to router) with uptimes around 2-3 months
• We have no crashes or unexpected behavior recorded caused by WampSharp

Thank you for all your work!
Esso

[Jopie64]

Hi Elad,

I also consider WampSharp ready for release. For a long time already actually. There haven't been major issues for a long time, and the issues that are found are resolved quickly and professionally in my view, or are issues with third-party libraries. None of them affected our software.

We are not as heavy a user as @esso23, but are using it in a complex WPF client application with the JSON transport usually with a home-made router in C++. We tried the router functionality of WampSharp which works fine but don't use it due to practical reasons. We are also developing .net core server applications with Wamp which run in docker or as a Windows service, but they're not released yet.

Thanks for this great lib!
Johan

[quynh-ng]

Hi Elad,

We've been using WampSharp in production for ~2 years now and we are very satisfied with it.

• Targeted platforms: Windows Server 2012/2016
• We're using both router and client
• The router runs as a Windows service, we're using WebSocket/Json transport for the first year and WebSocket/MsgPack for the second year to now.
• We are using WampSharp clients (from IIS and other Windows services), and got 30 - 50 clients connected at the same time (working hours)
• Sometime we got crashes of IIS (at the Application_OnEnd event) when try to perform async disposal (because IIS not allow async task at the state), but the crashes was raised by Reactive lib.

And we got 2 meetings with network monitoring team to explain and tell them why too much packages between our servers.

Thanks for your work.

[burningice2866]

Hi Elad,

C1 CMS Foundation is an open source CMS system which is using WampSharp for client-server communication in the backend. I was first introduced on February 9th, 2017 and has been in the CMS since.

WampSharp is being used as a router being hosted in-memory of a Web Application running on IIS. A custom javascript framework running in the browser will then talk to the router via WebSockets.

The current requirement of C1 CMS is .Net Framework 4.6 but will soon be 4.7.

The first version of the WampSharp.AspNet.WebSockets.Server was actually submitted by the C1 CMS project.

[StevenBonePgh]

Hello Elad - apologies for being late to the discussion. I agree with the preceding discussion that WampSharp is ready for prime-time. The last time I needed to debug into WampSharp code was over 6 months ago. The code is written, architected, and documented very cleanly. I use WampSharp for RPC and Topic. I use WampV2 internally (IPC, both client and router bits) and WampV1 externally (3rd Party API, Router as primary use, client as part of a client sample). On the 3rd party API side one is using WampSharp, others are using unknown implementations of WAMP. OS Windows Server 2008-2012, Framework is mostly 4.5.2. We are using Fleck on Router Side, WebSockets4Net on client side, mostly to limit test scenarios however I have tested with selecting transport based on OS with success. I am only connecting to other WampSharp routers.

In terms of stability, uptimes are measured in months, no downtimes due to WampSharp, and no bugs or crazy workarounds needed, In terms of message rates, nowhere near @esso23 - peaks at hundreds per second, to idle for minutes at a time. Been running this since late 2014 as WAMPV1 on about 30 servers, and the WAMPV2 bits for about a year on about 5 servers.

The WAMPv2 endpoints are being used in scenarios where I would have used WCF in the past. I've found WampSharp to be easier to configure and troubleshoot, with much less worrying about the typical Channel Faults and other nonsense that you almost never see in testing but always see in production.

On the 3rd Party API side, I'd like to support WAMPv2 as well as WAMPv1 - to do so I'd like to host via OWIN and share a listening port with a WebAPI Rest endpoint (I have not experimented here yet). On a 3rd party sample perspective I'd like to be able to auto-select the WAMP version - unfortunately (and correctable) the exceptions raised in WAMPv1 and WAMPv2 do not share a common base class therefore client code that is otherwise agnostic to WAMP versioning would need to catch two different exception types for what is to them the same exception. Like I mentioned, I have not gone down this path fully so I also do not have more specific comments other than the obvious Exception differences, and I didn't plan on raising this or a pull request after I had more time to consider this properly - I mention now only because some may consider this a breaking change in an otherwise stable API.

One suggestion that I have is to include source-indexed symbols in your packages. When I have needed to debug, I had to pull the source, build it, replace the package binaries with what I built including the PDBs in order to do so. Diagnosing anything via a minidump (like the IIS Task that never completes) would be impossible without symbols, and source indexing makes stepping into, if necessary, incredibly easy. The method described in the above link is ideal for GitHub projects, and dealing with libraries that publish to symbolsource.org is an extra step to remember (to enable then disable the symbol source, and hope the symbols are indexed or that is a lot more work).

[darkl]

Thanks all for your supportive comments!
WampSharp will be released as a non-prerelease version in about 4 weeks from now. We will also replace versioning with CalVer, so this version will probably be 18.03.1.
GitLink will be included in this version, assuming this won't be too hard to setup (WampSharp has a lot of sln files, hopefully this won't be a problem).

Feel free to write further supporting comments here.
Elad

[darkl]

Done! See WampSharp 18.3.1 on NuGet gallery!

Elad