I heard that when a request goes from browser(client) to IIS ,after extension filtering
(aspnet_isapi.dll)several named pipe connections are established between the ISAPI DLL and the worker process(w3wp.exe).
What is the name of those pipes ? will those pipe acts as a communication channel like the one we have with WCF?
You will find here a superb explanation by Rick Strahl of how ASP.NET works, and yes, named pipes are used in IIS5 for communication between the ISAPI DLL in the inetinfo process and the worker process, but in IIS6 this is no longer necessary since the lowest level of the HTTP stack was transferred to the kernel driver HTTP.SYS, which passes the requests directly to the worker process.
Named pipes are objects managed by the operating system kernel, for which there is a specific Win32 API. WCF named pipe bindings are built on top of these, but involve a great deal more layered on top of the raw pipe transport. Even in IIS5 where named pipes are used for ASP.NET, these are not used in anything like the same way that WCF uses them, so there is no reason to think of them as connected or analogous in any way. The types in the System.IO.Pipes namespace are a nearer comparison, being much thinner wrappers over the OS pipe API.
This is just a binary pipe, one of standard ways to communicate between processes in windows (the others are shared memory and com+ iirc). You can have several worker processes, obviously, so i am not sure there's one single name for the pipe. And i highly doubt this is using any kind of .net serialized data - not sure about this.
Related
QtConcurrent is extremely convenient as a high-level interface for multithreaded processing in my data-heavy/CPU-heavy application. The Qt6 upgrades vaguely referenced "Revamped Concurrency APIs" but I didn't see much change, except a reference to being able to pass a custom QThreadPool.
That got me wondering... is it possible to extend QThreadPool into a class that manages threads/tasks on other machines, not just the host machine? Or is that too far from its original design? Or is there another Qt class that can manage distributed processing?
Don't bother linking me to non-Qt solutions. That's not the point of this question.
QtConcurrent doesn't deal with any of it, unfortunately.
In a most general approach, you only need some worker machines on the network, and a way to connect to them via ssh (if they are Unix), or via Windows credentials (on a Windows network). At that point you can send a binary to the worker and execute it. Doing this in Qt is of course possible, but you'd need to wrap some other libraries (e.g. Samba for RPC calls, or openssh) to do that.
No matter whether the software can "distribute itself" or is otherwise installed on the workers, you got it running on multiple machines. Now they have to communicate, with one being a master, and the other being slaves. Master selection could be done via command line arguments, or even by having two binaries: workers that include only the back-end functionality, and a front end that includes both (and has some sort of UI).
At that point you can leverage Qt Remote Objects, the idea being what you'd "distribute" is QObjects that do work in the slots, and return results either via return value of the slot, by sending a signal. It's not as convenient as using QtConcurrent directly, but in general there's no way to distribute work transparently without some introspection that C++ doesn't quite provide yet.
I know that OpenMPI is not a Qt-based solution, it certainly works and makes life easy, and for sure it can interoperate with Qt code - you can even distribute methods and lambdas that way (with some tricks).
If you manage worker objects encapsulated as QObjects, it's not too hard to distribute the work in e.g. round-robin fashion. You could then have a front-end QObject that acts as a proxy: you submit all the work to it, and it signals all the results, but internally it invokes the slots on the remote QObjects.
Would you be interested in a demo? I could write one up if there was enough demand :)
I need to implement simple file watcher utility. I have decided to implement this in a simple windows service which will internally use FileSystemWatcher. The purpose is to monitor given directory path (or ftp) and copy the file to some other server wherever new file comes in after checking some predefined logic
As I am using .net 3.5; client suggested me to use WCF. I have very less experience in WCF.
I am not sure how I can create WCF service which will function like WindowsService and can be deployed in services on windows server.
To be a futuristic is it a good idea to create WCF service instead of windows service, or I should insist on window service.
Windows Service != WCF
You can't create a WCF service that acts functions like a windows service. A WCF service waits for messages from third parties and acts on them, a windows service is a process that is always running in the background. WCF tries to solve the problem of separating out the communication mechanism (transport protocols such as Tcp, Http, Named Pipe, etc) from the service interfaces.
File Watcher Utility
While in theory it's possible to create a new Flat-File binding in WCF that "could" have it's address set to a file system location, one does not exist directly in the .NET framework. Looking at the Custom Bindings article on MSDN it's not immediately obvious to me how one would construct a File System binding. These are the defined transport options available:
TCP
HTTP
HTTPS
Named Pipes (IPC)
Peer-to-Peer (P2P)
Message Queueing (MSMQ)
Custom
If communication must be done through file drops, then WCF does not solve your problem.
Where WCF Might Work
What the client might have meant is to create a WCF endpoint that does the copy the file to some other server wherever new file comes in after checking some predefined logic, but you would still want to have a windows service with a FileWatcher monitoring the input directory.
If you have multiple clients that need to be able to perform that same logic and then send the output to that other server then it might make sense to make the WCF service, otherwise it's over-engineered at this point.
You should choose the simplest option until you find a need to change, with the simplest option being a Windows Service.
There is a coding principle call YAGNI (you ain't gonna need it) that applies in this case as simply wrapping something up in a WCF service would do nothing but add unneeded complexity for the majority of cases. Simply put do the minimum viable solution and extend only when you need to.
PS. If you are using the FileSystemWatcher over network shares note that there are documented problems with it and you should use a combination of a poll + FileSystemWatcher. There are lots of explanations on Stack Overflow about it.
In your use case, the Windows Service makes a lot more sense and I think that to be the more appropriate solution. You need something that is always running and monitoring a directory and thats exactly the use case which Windows services are very good at.
I would consider talking to the client and explaining the Windows Services are the more appropriate solution to this kind of use case. Also, windows services are not old hat, they are there to solve exactly these kinds of use cases and WCF / windows services complement each other.
Both features have Service in their names by they have virtually nothing in common.
A Windows service runs constantly on a single machine.
A WCF service is code than can be called remotely by other machines.
It simply depends on what you need to do. A Windows Service and a "WCF service" have little in common.
The question here is whether you need a HTTP endpoint or not. If you do, you could even host a WCF service in your windows service to provide that. Keep in mind that a WCF is only used as a way to communicate between applications.
Reading your description, though, it doesn't seem like you need it.
WCF Service in a Managed Windows Service
I need to find the most efficient way to communicate from an asp.net web server and a windows C++ application. The windows application does not have any permission to access the database of the asp.net web server.
When the user presses a button, that action with some bytes should be received by the C++ application.
In return, after processing the data on the C++ application, it will send back the result to the web server.
The only way I can think of at the moment is as following:
The asp.net web server will have two web service methods:
the C++ application will call that web service for a method for an interval. if there is a change, then the C++ application will process.
after the C++ application finished its process, it will call a method on that web service to inform about the result.
Any other ways to solve this kind of communication?
Thanks in advance.
If the C++ Application is also on Windows, named pipes would be a good solution. They can be configured to be durable so they can queue messages if either side is not ready to receive the message and they are quite easy to use. They basically look like files that you can read or write from and the data appears on the other side of the "pipe".
Take a look at the documentation (C++) here: http://msdn.microsoft.com/en-us/library/aa365781(v=VS.85).aspx
On the ASP.NET side you would use .NET API's. Here's a nice example to get you started: http://msdn.microsoft.com/en-us/library/bb546085.aspx (This example includes both client and server code.)
Named pipes would be a great solution if the C++ application is located in the same physical server as the ASP.NET application. In that case the OS would be just moving memory between processes for you so it could be very quick.
Additionally, I would configure the C++ Application as a Windows Service so it's always available and can be restarted when the server it's running on is restarted. If keeping it running is very important you could integrate Performance Counters and then have your ops team monitor the counters to make sure it is operating within expected thresholds.
The C++ application can also make a simple GET or POST request with enough information that the webserver can handle in case you don't want to expose a webservice.
You could use network sockets. It's been a long time since I have done anything with them so I can't be much help. Research Winsock (aka Windows Sockets API).
You could use WCF services and connect to them using your C++ client. You will have to research consuming WCF services from C++ client.
As #parapura suggested you could use simple HTTPRequest get & post methods. You could create your own http handler for these request to customize the response.
As you suggested you could use simple web services.
Hey,
first of all this is a conceptional question and I do not know if StackOverflow is the appropriate place - so my apologies if I am wrong.
Nowadays the web is not only used for passing raw informations. Many and especially complex web applications are in use. These web application seem to be so complex that it seems irrational to use the HTTP protocol, which is based on so simple data exchange, plus it is stateless.
Would it not be more convincing to use remote invocations for this web applications? The big advantage to my mind is a unified GUI by using HTML. But there are applications, which have no need for a graphical interfaces and then it comes to a point where the HTTP protocol is really cumbersome.
Short answer: HTTP is allowed through firewalls where other protocols would be blocked.
A short partial answer is: first, for historical reasons - HTTP was used since the dawn of the web as protocol for requesting documents, and has since been used for some different purposes. One reason to keep using it is that it is generally served on port 80 which you can be sure won't be blocked by firewalls between your client and the server. The statelessness of the protocol may not always be what you want, but it has at least the advantage of protecting the server side from very trivial overloading problems.
OS independence
firewall passing
the web server is already a well understood and mostly "solved" problem in terms of load balancing, server fall over, etc.
don't have to reinvent the wheel
Other protocols are being used more and more now, including remote invocations and (the one I am particularly familiar with) WCF (which allows binary TCP/IP data transfer).
This allows data to travel faster for applications which require more bandwidth. For example an n-tier application may use WCF binary transfer between application and presentation tiers. Also public web services allow multiple protocols, including binary.
For data transfer protocols, firewalls should be configured (ie. expose a port specifically for your application), not worked around, I would not recommend using a protocol because firewalls do not block it.
The protocol used really depends on who will consume it and what control you have over the consumption - eg external third parties may need a plain-text version with a commonly agrreed data interface. On the other hand, two tiers in a single web application may be able to utilise binary data transfer for performance and security.
Earlier on I've implemented a custom C++ server from scratch, something which is nice and fun to do but is very time-consuming.
So I've heard about "servlet" of Java which sounds like something I'm looking for for my next project.
I'm looking at ASP.NET to be used as a servlet because it's pretty much mature in terms of networking capabilities and programming features and I can write code for it in C# which is a language I already know and feels good with.
Anyway before getting into it I'd like to get concise answers regarding some of the capabilities that ASP.NET may provide me with.
My client application is Flash-based and has nothing to do with XML or HTTP protocols (raw sockets).
1) Can I accept raw (in terms of protocol) socket connections and keep them alive as long as needed?
2) How hard/complicated is it to apply AES encryption over a connected socket?
3) Can I have a "shared", in-memory, objects, like lists, over the application's instance?
4) Can I get one message from client X and send a copy/reply/report (on the fly) to client Y, without using a database or anything like that? This question suggests question #5.
5) Can I identify a connection by its memory address or object address, so I can refer to it directly?
6) Can my application be distributed over several servers?
7) How hard/complicated is it to scale such an application? For 10 concurrent connections there's no problem but for 50,000 I can surely expect load issues.
8) Finally, the most important question which probably has the most complex answer: How flexible is the environment from a programmer perspective? I mean, can I control events such as "on_connect", "on_disconnect" and stuff like that? How hard would it be to access connection Y from connection X's event (such as "on_data_received")?
ASP.Net is more like JSP than Java Servlets as it requires a web server to run. Typically IIS is used since Microsoft has built in ASP.Net support there, but it's possible to run ASP.Net on other web servers. As a web server product it's all HTTP and therefor connectionless. Based on your questions 1, 2, 4, 5 and 8 this may be a deal-killer for you.
If you can code your Flash application to manage itself with HTTP/HTTPS connections then using ASP.Net to build out web services that your app can use is a decent option. IIS is mature and can scale out nicely (q's 6 & 7). It also has an application-level store that you can use (q3). Of course each server in a farm would have its own copy.
It's possible to implement your own server in C# with a lot less effort than in C++, but it's still a time consuming endeavor. The TcpListener class in System.Net.Sockets would be the starting point if you chose to go that route.
I would go with Client/Server .NET application, not ASP.NET as it's out of its "scope".
Unless one of the demands is to have public website?