I'm looking for a small and fast library implementing an HTTP server in .NET
My general requirements are:
Supports multiple simultaneous connections
Only needs to support static content (no server side processing)
HTTP only, HTTPS not needed
Preferably be able to serve a page from an in memory source. I want to integrate it into another app to be able to make changing data available via a browser, but I don't want to have to write it to a file on disk first. For example, just pass it a C# string to use as the current page content.
Preferably open source so I can modify it if needed
Definitely needs to be free... it's for a personal project with no budget other than my own time. I also want to be able to release the final product that would use this library freely (even if that means complying to the particular OSS license of that library.
Edit: To clarify some more, what I need can be REALLY simple. I need to be able to serve essentially 2 documents, which I would like to be served directly from memory. And that's it. Yes, I could write my own, but I wanted to make sure I wasn't doing something that was already available.
Use Cassini.
Free, Open Source.
It would take trivial hacking to serve from memory.
Well, how complicated of a HTTP server do you need? .NET 2.0 has the HttpListener Class which you can use to roll your own basic library. Since this is for a personal project and you are willing to invest the time, it would also make for a good learning experience as you you would get to learn how to work with the class. Additionally, according to the MSDN documentation, it has an asynchronous mode that gives each request its own thread.
Getting a basic HTTP server with the class up and running isn't too difficult either, you should be able to get it done in only a couple hundred lines of code.
Check out Kayak.
Note: kayak doesn't seem to be maintained anymore - though it deserves to be so
LightHTTP is an open-source library I've created that does exactly what you need.
It can be used in testing and mocking, or other scenarios where a lightweight HTTP server is preferred.
It works asynchronously.
Supports simultaneous connections.
It can serve anyway you'd need, since it's based on HttpListener.
Related
We have a background service, which has the single purpose of getting recent data from a server.
Now the server should be an OPC-UA server. Unfortunaly, the SDKs and examples I found to connect to this are limited/only explained in ways that are heavily integrated with a classic windows forms application. Up to the point where its impossible to separate GUI from business logic.
At this point I'm wondering if we are misusing the client functionality and should opt for a different way?
Ideally I'd like to wrap the whole OPC-UA Logic inside a class library and just call GetData(), is that impossible?
You are probably referring to the "SDK" provided by the OPC Foundation - but you have not stated that explicitly in your question; in fact, you used the term "SDKs", in plural. There certainly are also commercial SDKs which might be better in this respect.
Here is one (QuickOPC), together with one-liner example of reading the OPC UA data: https://www.opclabs.com/products/quickopc/opc-specifications/unified-architecture/generic-data . Disclaimer: This is a self-promotion.
You might find Tutorials for Client development, specifically Console Client useful. This is a much better SDK than the one from the OPC Foundation. You will find full C# samples including a console client application (no GUI).
You might want to re-evalute your needs for
Ideally I'd like to wrap the whole OPC-UA Logic inside a class library and just call GetData(), is that impossible?
It is totally possible, but with OPC-UA, you have to keep in mind that it is recommended to get data using a subscription model (Monitored Items) instead of performing an explicit Read for a value (unless you just want to read an attribute once). So, I would make sure that however you are building your client-side class makes sense for the needs of your application.
Overview
I'm currently working on a media streaming server using ASP.net Core REST Server. I'm currently using .net 5.0 and ASP.net Core MVC
What I need
I need to be able to dynamically down-res the original video file. from 1080p to 720p for example.
Also I need to be able to make the media file able to be transcoded to a different encoding based on client capabilities.
What I've Tried
I've been looking for a library that can manage this feat, but I can't seem to find one. I thought FFMpeg would be able to do this. I know this is possible because applications like plex and emby seem to manage this.
What I've Done
[HttpGet("/api/streaming/video")]
public IActionResult GetFile()
{
string path = "C:\Path\To\Video\FILE.mp4";
System.IO.FileStream stream = new(path, System.IO.FileMode.Open, System.IO.FileAccess.Read);
Microsoft.AspNetCore.Mvc.FileStreamResult file = File(stream, "video/mp4", true);
return file;
}
Framework Tried
Xabe.FFmpeg
FFMpegSharp
Given that you need this to work cross platform, as #Andy said the best solution is ffmpeg. You have two choices:
Invoke the ffmpeg command line utility from your web process; or
Compile the libav library suite (which underlies ffmpeg) to each native platform your code might be run on - Windows, Linux, etc. - make a native DLL wrapper, and use P/Invoke in your ASP.NET project to access it.
Command Line Utility
The command line utility is very easy to use and well documented. Documentation is here. Your basic approach would be to include ffmpeg.exe in your web project (make sure you have a version for each platform), and use Process.Start to invoke it, using the command line arguments to point it to your video file and configure the output. Once the output is finished, you can serve it by returning with File like in your example. There are also some open source .NET wrappers like this one that could save you some of the work. Unfortunately the command line utility doesn't offer much (any) control once started, or a programmatic way of determining progress. However, these issues should not be a problem if you follow my recommendation at the end.
Libav
If you do need or want total control, however - including frame by frame transcoding, progress reporting, etc. - then you would need to use libav. Before going further, note that you need to use at least some C/C++ to use libav. That means your server code is going to have to run with full trust, and you WILL be susceptible to the security risks of running native code. (Though the same would be true if you used ffmpeg.exe, but at least in that case you don't run the risk of introducing NEW security risks through your own code).
Also know that you can't just find nice clean, always up-to-date downloadable binaries for every platform (at least one reason for which is fear of patent lawsuits). Instead you have to build it yourself for every platform your code might run on. Find your platform(s) on here and then follow the instructions to the letter. If you make a single deviation no matter how small, you won't be able to build it, and you will pull your hair out figuring out why.
Once you have the builds, then your next major task is to expose the APIs you need to your C# code. The documentation for the libav APIs is not a model of clarity. They more or less assume you will look at the code for the ffmpeg command line utility to figure out how to use libav, and that's what you should do. But if you invest the time (days if not weeks) to construct the builds and learn the APIs, you will become a Master of Media. There is virtually nothing imaginable that you can't do using libav.
Now you're finally ready to integrate this into your app. Again you can take two approaches. If you're quite comfortable with C/C++, you should make a new C/C++ DLL project, link the libav DLLs to it, and do most of the heavy lifting there and just export couple of entrypoint functions that you can invoke from C#. Alternatively, you can P/Invoke directly to the libav DLLs, but you will need to do a ton of scaffolding of data structures and functions in C#. Unless you're extremely comfortable with marshalling, I would not attempt this.
In fact, I'm going to recommend going the command line utility route, because -
You Shouldn't Try to Transcode On The Fly Anyway
With all that out of the way, let's talk about your actual gameplan. You said you need to "dynamically" convert the video based on what the client wants/can receive. No one does this. What they do do is create multiple versions of the videos in advance and save each one on the server e.g., a 1080p, 720p, 480p, and maybe even 240p version. Then, the client application monitors the connection quality and, also considering the user's preference, directs the media player to the desired version. The server always serves the version requested and doesn't convert on the fly. Unless you're talking about streaming live events - and if so then that's beyond the scope of my expertise - this is what you should do.
So, what I would advise is use the ffmpeg utility to create different versions of the videos in advance - as part of an import or upload process for example. Track the videos in a database including what versions are available for each. Give the client a way to obtain this information. Then when it comes time to serve the videos, you just serve the one the client requests in a query parameter. Put the logic for determining the desired version on the client - either connection speed and/or user preference.
And Don't Forget to Support Content-Range Requests
Finally, you probably don't want to just use File to serve the media unless the users are just going to download the files for offline viewing. Assuming people are going to play videos in a browser, you need your API to accept content-range request headers. Here's a pretty good example of how to do that. Provided you implement it correctly, web browser media players will be able to play, seek, etc., transparently. If for whatever reason the format needs to change, just redirect the URL of the media player to the appropriate version, keep the position the same, and resume playing, and the user will barely notice a skip.
Hope at least some of this helps!
Is there any wrapper that would allow me to access and modify raw request data (like the headers, body, cookies directly from the webbrowser object in winforms application using c# ?
The only thing I've seen out there which would let you interrogate what the browser is doing is Fiddler, which has an API. You might want to check that out, but it's not something that I would personally consider using to ship inside my production software unless I had a real solid requirement for it.
You can also try to implement your own Asynchronous Pluggable Protocol. So you'll be able to access and modify requests and then forward them to the destination using, for example, HttpWebRequest or raw sockets.
Some links you might consider useful to get started with:
A Simple protocol to view aspx pages without IIS implemented in C#
Internet Explorer Asynchronous Protocol Library
Although, using Asynchronous Pluggable Protocol in this case still looks like a hack (at least for me).
OK... So I've spent the last 4 days scouring the net for a solid solution to needing functionality like this. Mainly, being able to access the raw outbound request, and the raw inbound response associated with the webBrowser control in .Net. The results are absolutely disappointing. Why is this such a huge deal? Why can't MSFT just fix that control and add properties for the rawRequest and RawResponse? If you look you'll find developers trying to hack their way around this for the last 5-10 years. And nobody has come up with a solution? Really? WTF???
"WebBrowser.CreateSink Method"
Huge can of worms. Going here will break your mind.
"The most complete C# Webbrowser wrapper control"
On Win7, trying to regsrv32 the required old ass ATL DLL from 2006 results in an
Error.
"Subclass the WebBrowser control"
Won't work to gain access to the actual request/response HTTP packet data.
...sigh
I am starting on a fairly basic Server/Client application (logic wise), but I am a bit confused as to what I should use for my needs. It looks like there a few options, but basically I am going to have a Master Server, and X amount of client applications (one per dedicated machine). The main purpose of this setup is so that I can basically do the following...
-Issue command to server (console app) via an ASP front end to install software on one of the remote clients.
- Server tells client to download zip package (from a various FTP site) to location and extract it to specific path.
I am not positive, but it looks like C# has Sockets and then some sort of WebClient type of deal. I am assuming Sockets would be the best route to take, and to use asynchronous (each remote client is connected in its own thread, dealing with the server individually of others).
Any information on this would be great!
Without going into too much detail for your specific requirements, I would definitely look at WCF.
It encompasses a lot of the existing remoting, client / server, web services scenarios in a very complete and secure framework.
Client Server Programming with WCF
WebClient allows you to make HTTP requests, so I don't think it's very relevant here.
There are many approaches you can take for this app.
One is of course going with WCF, which provides about a million time more options than you will need. However, WCF does have a learning curve and in particular it's hard to understand what exactly is hidden behind all the abstractions without prior experience. Furthermore, this solution is not available if you are targeting .NET 2.0.
You can also implement a simple TCP client/server model using sockets. While you can program against raw sockets, .NET also offers the convenience classes System.Net.Sockets.TcpListener for the server and System.Net.Sockets.TcpClient for the clients. This approach is much closer to the metal, but this is a tradeoff: it's much easier to understand what exactly you are doing, but you will have to implement a fair bit of functionality yourself.
Is there a product (ideally open source, but not necessary), that would enable a zero dependency deployment? every service bus or queue library I've been able to find has a dependency on one of the queue apps (like msmq), or a database. I would like a very lightweight solution that I can just add a reference to my application, build it, and deploy it with as little configuration as possible.
In an ideal world, the queue/service bus would run on IIS, and allow web and rich clients to talk to it.
Such a tool would be ideal for fast prototyping of large distributed systems on a local development machine.
Rhino Queues from Ayende is exactly what you are looking for, this is the blog post introducing it:
http://ayende.com/Blog/archive/2008/08/01/Rhino-Queues.aspx
I think that all of the limitations mentioned in this post have been fixed since then.
From the blog post, what rhino queues is:
XCopyable, Zero Administration, Embedded, Async queuing service
Robust in the face of networking outages
System.Transactions support
Fast
Works over HTTP
In a similar vein to ShuggyCoUk's suggestion, you could rig up a queue (or queues) using the Windows built-in ESENT database (comes already installed with Windows). There is a managed code access library (open source): http://www.codeplex.com/ManagedEsent. If you stick with writing / reading CLOBs or BLOBs, it should work just fine. If you want to be really clever, you can use NServiceBus and write (contribute?) ESENT-flavored subscription storage and transports. There are some forays into using ESENT on Ayende's blog as well (you'll have to poke around his SVN repository for the juicy bits).
If you're happy to be:
Windows specific
Limited to the local domain
Seriously limited in the message size supported
Wrap the underlying win32 calls in P/Invoke
Deal with the polling yourself
Deal with the hacks needed to allow back and forth communication
Deal with the shared config needed to keep the names in sync
Then a quick wrapper around the windows MailSlot API might be sufficient.
This simple example is a reasonable basis to start.
This article has some further information but assumes the use case is via a control (rather than a Component as it should be) as well as some poor WinForms integration so should be considered for incidental reading rather than a basis for any library.
This article is C++ but is of a higher standard (and a commenter has extended it to support the batching of larger messages into several smaller ones).
You get 424 bytes (so with .Net 212 chars) you may want to drop to ASCII to double your useful message length if you are talking text.
Note that despite its simplicity, limitations and lack of features it does provide multicast delivery, something often complex to layer on a point to point protocol yourself.
This ayende post provides and interesting comparison of three service buses. We use NServiceBus and think if it's not clear that Udi Dahan would respond to how you'd plug in non-dependent queue.
We work using MSMQ happily but there are other options and in theory it should be open to practically anything, given that you may lose some reliability and durability depending on your choice.
Why not Amazon's message service Simple Queue Service?
We moved our projects from MSMQ to ActiveMQ. its really better :)
ActiveMQ is open source queue ,based on Apache web server.
We used him in production on high frequently data workflow, where msmq have a lot of problem (we work with msmq a year)
The csharp implementation is nms
I'm currently working on an open source WCF based service bus. You can find it here: http://rockbus.codeplex.com/. It supports dynamic (#run-time) subscriptions, subcription repository (database), pluggable transports, XPath based content-based routing, transactional delivery over wcf protocols, roundrobin delivery, pluggable subscription evaluation, and more. Have a look!
Have you thought about using a service like IronMQ by http://Iron.io?
You wouldn't have any dependencies, could quickly prototype apps without setting up any queue infrastructure, and it's highly available and fast.
There is not currently a locally installable version but it's based on the upcoming OpenStack protocol so there will be.
Btw I work for Iron.
Try https://github.com/mcintyre321/PieQ - this is my attempt to write a threadsafe, persistent, zero-config, embedded work queue. It probably needs a little love, but I think it might be the kind of tool you are looking for.
I have developed an InMemory JMS library which can be used to in testing JMS applications without really connecting to JMS providers/server (Think of hsqldb). You don't have to deal with connection or protocol or anything, all you need to do is to send and receive messages.
https://github.com/Dhana-Krishnasamy/InMemoryJMS