I found that puppeteer sharp is best way for server side, HTML to PDF conversion as it uses and downloads latest chrome and runs headless in background so the conversion is top class. tables and all else is rendered perfectly.
However for running on server, how should the concurrency be managed, because i think each web site users conversion request will launch another chrome instance. how does puppeteer sharp manages concurrency.
is is better to split it as separate web service and enqueue conversion requests and pass all pdf related requests to be served on one by one basis instead of running into concurrency or resource issues on webserver for multiple chrome instances.
I found this is the most scalable way to implement this is by using a background process. This is one real-life example:
A WebClient request a PDF sending a signalR message.
The SignalR hub creates some kind of an ID, put the request in an Azure Queue, and adds the SignalR client to a SignalR group with that ID.
A console app would read that queue, process the HTML, and sends back the result to the server using a SignalR message.
The WebServer will get the message, and broadcast that message to all the clients in that group.
It might sound quite complicated, but it's not that much. You can make it simpler.
Related
I have a web page for data processing. Web page waits for data to process.
And I have a C# application for data. I want to send data to open web page. But I don't want to use socket, Post/Get methods or any web request.
Web page and C# application are client side. They run in same Windows at the same time.
I want to send data to web page from C# app. This operation need to be done with Windows OS or some command line based trigger mechanism.
Web page (Chrome tab or Firefox tab; it doesn't matter) should have tab id the work on. With using this id I may be able to send data to web page from C# app.
But I couldn't really find anything useful.
Is there any way to do this? Is it even possible?
Any advice appreciated.
The way I would approach this is this, assuming you are using either WinForms or WPF:
In your application, embed a web browser:
WPF: https://www.wpf-tutorial.com/misc-controls/the-webbrowser-control/
WinForms: https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/webbrowser-control-windows-forms?view=netframeworkdesktop-4.8
Load the web page in that browser
Establish a two-way communication between your client application and the web page:
https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/implement-two-way-com-between-dhtml-and-client?view=netframeworkdesktop-4.8
If using other technologies let me know and I'll update answer.
One solution is Raw TCP/IP connection on browser but it's not yet fully supported and implemented. If by Web requests you mean online requests then what #DevRacker said is the best I know, too.
However consider TCP/IP, Web sockets and even REST-APIs are frequently used for Inter-Process Communication (IPC) too, when there is no online transmission of data and the data/command is only transmitted over a local machine.
If I were you, I would use Web sockets or maybe a simpler solution such as Socket-IO.
I am trying to use web sockets to allow two Windows services on different machines to pass data back and forth. Almost all the examples or information I have found are about using web sockets for Client/Server Side communication. I am having trouble figuring out how to set this up. I have considered using WebSocketHost as apart of Microsoft.ServiceModel.WebSockets, but then I am unsure how to bind it to a local port and not a URL.
Does any one have any suggestions
Thanks
I am trying to use web sockets to allow two Windows services on different machines to pass data back and forth.
You can open sockets on both machines using WebSockets as you found. The examples mention clients and servers because this is the typical usage, however the API really doesn't care. As long as each side has a listener and a sender they can communicate.
However I would like to mention that this isn't as simple as it sounds because both machines aren't always available. Sometimes one or the other is busy or the network is blocked or something else is going on, or the listener is too busy to respond right away, so you're going to end up needing some sort of queuing on both sides.
If you're doing a process based operation where one side tells the other "I want X" and it's a big operation like producing a document, I've found it much more resilient to build a queue in a database and toss the request in there, then wait for the other side to update the record to say it's done.
If they're smaller, faster requests, MSMQ would be more appropriate if you have it available.
However back to your original question, if you want to use it, any of the client-server examples should work just fine. The API doesn't care.
You can use SignalR Self-Host you really don't want to create your own WebSockets framework since this this will take a long time.
Here is a link on how to start a OWIN server in Windows services.
Hosting WebAPI using OWIN in a windows service
And how to set signalR in self host
Tutorial: SignalR Self-Host
You can accomplish this with Memory Mapped Files.
Inter-Process Communication with Memory-Mapped Files
From my understanding, the beauty of signal R is that it takes care of the "handshake" between the client and server to determine the best form of communciation between them (websockets, long polling, etc). I understand that by default it does this at the /signalr route. I read that before this the handshake would be accomplished with an HTTP Get request with an Upgrade/Connection header specifying to upgrade to this new connection.
In my current application we support handling many HTTP requests in a RESTful manner. If we wanted to expose some of this data in real time rather than in this request response format, what would be the best way to determine if we should open a connection using signal R? Would checking for those headers still suffice? I just feel like that is a bit redundant since signal R abstracts that away.
Instead of this, would a solution be for the client to specifically invoke a hub method to kick off the streaming as soon as he connects to the proper endpoint?
TLDR: Need a way to open a signal R connection from a HTTP request, don't know the best way to go about that whether it be from requesting the resource with custom HTTP headers or by just navigating to the url resource and having their client invoke a hub method.
A typical example of using signalr is:
an html file using JavaScript to connect to a signalr Server when the page is loaded. we call this signalr client.
a signalr server written in c#. it can be a winform or console or service.
the signalr Server can call any dll, or webservices or webapi located in the same server, or even in different Server.
then, the client can call any function defined in the signalr server. the server can call any function defined in the client for a particular client or for groups of clients.
also, client x can call client y functions as well.
I would also suggest you create this index.html inside a Cordova project, so that your client can use this app using any pc desktop browser, or any mobile phone browser, or run it as an Android or iPhone native app, by using One set of client codes.
if they navigate to some url resource instead of receiving a response with json in its body we want them to be constantly in real time using signal r receiving data
I don't think this is possible with SignalR. Reason is that all SignaR communication is done through single route (xxx.xxx.xxx.xxx/signalR) + all SignaR connections are established using handshake (By client sending negotiate request to this route. Well maybe not all - not sure if negotiation is happening in case you initialize SignalR connection object with specific transport).
Ok so i have a C# server and a windows phone app that acts as a client. The client will have to modify settings on the server, receive images from the server (possibly a video stream) and receive notifications from the server (the best way would be instantaneous, like when someone sends you a message on facebook and you get the notification right away).
I have the server and client set up so they are communicating, they are sending each other an object that is serialized with XmlSerializer (it currently only contains a public String field with public get/set methods). They connect over a socket. This works well if i want to send just simple messages between them, but i assume i'll run into problems when i want to have instant notifications and transfer of images / video streams. How would i go about continuing my work in a proper way?
Consider designing an API solution via web services using RESTful or SOAP services. Personally I suggest using RESTful web services. Here are some kick start links about REST:
http://www.codeproject.com/Articles/255684/Create-and-Consume-RESTFul-Service-in-NET-Framewor
http://www.codeproject.com/Articles/148762/NET-4-0-RESTful-Web-Service-Introduction
http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa
http://msdn.microsoft.com/en-us/library/dd203052.aspx
This is another useful article in MSDN which compares WCF REST and WCF SOAP: http://msdn.microsoft.com/en-us/library/vstudio/hh273094(v=vs.100).aspx
I think if you are looking for two way communication between the client and server then using sockets is the way to go.
As for images you don't need to send the actual image. You can just pass a URL to it and then download it with one of the classes specialized for that.
For near instant notifications you could also take a look at push notifications.
Of course if you don't really need the server to push data to the client then it would be much simpler if you used a REST API as someone else suggested.
I am currently working on a project which I think using soap as part of it would be a good idea but I can't find how it will work in the way that I need.
I have a C# Console Application called ConsoleApp, ConsoleApp will also have a PHP web interface. What I'm thinking of doing, is the PHP web interface controls the ConsoleApp in some way, so I click a button on the web interface, then this does a sends a soap request to a soap service and then the soap service, sends the information on to the consoleApp, and the result is returned back to the SoapService and then returned back to PHP.
This seems like it would need to separate soap services, one for php to interface with and one within the ConsoleApp but this doesn't sound right, I think I might be misunderstanding the purpose of Soap.
How can this be achieved. Thanks for any help you can provide
UPDATE
As requested I thought I'd add a bit more information on what I am trying to achieve.
In the console app, it is acting as an email server sending out emails that are given to the program and then being sent on, and if it can't send it retries a couple of times until the email goes into a failed state.
The web interface will provide a status of what the email server is doing, i.e. how many emails are incoming, how many are yet to be processed, how many have sent and how many have failed.
From the web page you will be able to shutdown or restart the email server or put one of the failed emails back into the the queue to be processed.
The idea is, when the user adds a failed email back into the queue it sends a soap message that the console app will receive, add the information back into the queue, log the event in the console apps log file, increment a counter which is how it keep track of emails that need to be processed. Once this has been done it should then send a response back to the web interface to say whether or not the email was successfully added back into the queue or whether it failed for some reason.
I don't really want to keep on polling the database every so many seconds as there could be the potential for their to be a large number of emails that will be being processed so polling the database would put a large load on the MySQL server which I don't want, which is why I thought soap as the email server would only need to do something when it receives a soap request to do something.
Thanks for any help.
Every web service is going to need a client (in your case PHP) and a server (ConsoleApp). Even though there are two endpoints, it is still one web service. Your PHP will send a SOAP request which ConsoleApp will receive, process and respond to with a SOAP response.
So when someone clicks the button on the web page, you can use JavaScript to build and send the SOAP envelope in the browser. The alternative is to POST the values to a PHP page that will build and send the SOAP.
I have to admit though, your scenario sounds a unusual. I personally haven't heard of web pages talking directly with console apps. Web pages usually talk to web servers, and the servers are usually the ones issuing atypical requests, like your request to ConsoleApp. While it is technically possible, but I think it is going to be harder then you are expecting.
Personally, I would ditch SOAP in favor of a much more simple and scalable solution. Assuming you have access to a database, I would have the PHP create a record in the database when the user clicks the button. ConsoleApp would then poll the database every X seconds to look for new records. When it finds a new record, it processes it.
This has the benefit of being simple (database access is almost always easier than SOAP) and scalable (you could easily run an arbitrary number of ConsoleApps to process all of the incoming requests if you are expecting heavy loads). Also, neither the PHP page nor the ConsoleApp have a direct dependency on the other so each individual component is less likely to cause a failure in the whole system.