I want to watch all the HTTP requests going out of a certain application and cancel them if needed.
Is there a way to do this in C#?
If you can touch the system's proxy configuration (which is used by many applications) or, if the app doesn't heed that setting, touch the application's configuration to use a proxy of your choice, you can create a HTTP proxy that would do the job for you.
If you just want to profile, there is a ready made tool that behaves like this and is very nice, Fiddler.
Else you'd have to go deeper into the network stack and implement something like a sniffer/firewall, for instance using WinPcap. That's a lot harder to do.
If you're working with Windows, it is possible to hook the WinInet API calls and do whatever you want with them.
FreeCap (or its commercial version, WideCap) does that: allows you to send TCP traffic through a proxy server. That proxy might then do the filtering (e.g. Fiddler).
I know this brings more stand-alone applications into the system, but it works.
Related
Is there any way of starting a HTTP WCF service from a regular, non-admin application manually? All I want is my regular desktop application to listen on a port where some things can be controlled remotely.
I could go the manual route and use my own TcpListener, parse HTTP (or any other protocol), go through some reflection, then respond back on TCP, but I'd like to use WCF to avoid boilerplate.
A partial workaround is to use http://localhost:80/Temporary_Listen_Addresses/ if that's acceptable in your situation (not in mine though). This URL magically doesn't require additional permissions. source
I have this Windows Service that communicates with TCP/IP.
What I want to know is a method for a Windows Form Application to able to modify the setting of this service, such as remote host address and port to connect, timeout length, and log settings.
I have researched about NamedPipe, WCF Service, and IPC, but I can't decide what matches my scenario the best.
Will be nice to able to change the service settings by doing something like this from the client side.
[Service].SetTimeout(3000);
Any suggestions?
If you want that kind of programmatic control, then WCF is your best bet. With WCF, you get to define the API yourself, e.g., what methods to call, what messages to pass, etc. The WCF framework takes care of exchanging the data for you. And with the WCF config files, changing the back-end data exchange mechanism is trivial. For example, you could replace a NetNamedPipeBinding used for same-machine communication with a NetTcpBinding for cross-machine communication simply by modifying the config file(s). Full disclosure, though, if you haven't done WCF before, my experience was that the barrier to entry was pretty high. Of course, I took my lumps with Visual Studio 2008. It might be much easier in a more recent version. Here's an answer I gave a while back with some tutorials that helped me.
For me personally, I've replaced the early WCF implementation with a TCP-based version over localhost in the project I work on. The front-end application receives constant information from the Windows service when things are "running," and at the time of our decision, WCF streaming was not documented very well. We also saw evidence of problems, although that might simply be because we did it wrong. In any case, I'm very pleased with the solution we've come up with.
I can't speak to named pipes directly, but from what I've read, they're easy to use.
HTH.
I want to develop a program in c# that can target and application or port's traffic and tries to view that traffic.For example,I select example.exe program in my application and it gives me it's network traffic data.
Is it possible?If so,give me some directions.
I'm trying not to use airPcap or winPcap or anything like these,because these libraries target the network card and I don't know what type of interface card the user might be using.
You have to either capture packets where you receive a duplicate from the NIC (pcap), or route requests through your own application so you can inspect the live packet flow (proxy-like).
For a WinPcap implementation in C#, take a look at SharpPcap. For a proxy, see here.
winPcap is a very good library for what you want to do.
If you choose to do it yourself, you will only be reinventing the wheel, and might not be able to support as many network cards as it does.
If you only want to see the traffic, you would have to use a proxy in between.
But I believe you are not looking to build something like, fiddler for example,
that sits in between and allows you to monitor the traffic.
If I understand you correctly you want make a c# app where you select from a list of running applications and display the network traffic to/from that app. You could do this with c# but you would have to make calls to the Windows API to get the information you need. In addition you will need non-c# library for packet capture sucgh as WinPcap. Windows has a new NetMon API that does pcap like things. I have not used it, but you probably way better off with pcap and the SharpPcap lib that CodeCaster posted.
I am confused how I would refresh the HTTP sessions on the client side whenever the data is updated on the server side. I am using ASP.net with C# and SQL Server DB. I don't want to implement a timer on the client side and want to push notifications from server side.
Just want to know if its possible and a high level understanding of it will be enough. Thank you.
I think you're looking for a Comet solution like WebSync.
Take a look at this answer's to this question.
HTTP, by definition, was not designed to "PUSH"... rather, it is designed, from the ground-up to PULL or POLL changes.
One of the major reasons for this is the ability to massively scale via caching on multiple levels (content storage level, web server level, proxy server level, client level, etc.)
To create a system where you PUSH changes, you'll have to resort to TCP/IP.
But, you do have a couple options for this:
Flash (Cross-Browser, Cross-Platform, Widely Supported, Requires Plugin)
Silverlight (Cross-Browser, Mac/PC, Less Supported than Flash, Requires Plugin)
ActiveX (IE, PC, Requires special permissions most times)
Can all be used to create a connection with the service and wait for updates to be pushed.
Emerging Options:
WebSockets http://en.wikipedia.org/wiki/WebSockets (Only supported in uber-modern browsers, not completely standardized yet)
I have developed a windows service which reads data from a database, the database is populated via a ASP.net MVC application.
I have a requirement to make the service re-load the data in memory by issuing a select query to the database. This re-load will be triggered by the web app. I have thought of a few ways to accomplish this e.g. Remoting, MSMQ, or simply making the service listen on a socket for the reload command.
I am just looking for suggestions as to what would be the best approach to this.
How reliable does the notification has to be? If a notification is lost (lets say the communication pipe has a hickup in a router and drops the socket), will the world end come or is business as usual? If the service is down, do notifications from the web site ned to be queued up for when it starts up, or they can e safely dropped?
The more reliable you need it to be, the more you have to go toward a queued solution (MSMQ). If reliability is not an issue, then you can choose from the mirirad of non-queued solutions (remoting, TCP, UDP broadcast, HTTP call etc).
Do you care at all about security? Do you fear an attacker my ping your 'refresh' to death, causing at least a DoS if not worse? Do you want to authenticate the web site making the 'refresh' call? Do you need privacy of the notifications (ie. encryption)? UDP is more difficult to secure (no session).
Does the solution has to allow for easy deployment, configuration and management on the field (ie. is a standalone, packaged, product) or is a one time deployment that can be fixed 'just-in-time' if something changes?
Withous knowing the details of all these factors, is dififcult to say 'use X'. At least one thing is sure: remoting is sort of obsolete by now.
My recommendation would be to use WCF, because of the ease of changing bindings on-the-fly, so you can test various configurations (TCP, net pipe, http) w/o any code change.
BTW, have you considered using Query Notifications to detect data changes, instead of active notifications from the web site? I reckon this is a shot in the dark, but equivalent active cache support exists on many databases.
Simply host a WCF service inside the Windows Service. You can use netTcpBinding for the binding, which will use binary over TCP/IP. This will be much simpler than sockets, yet easier to develop and maintain.
I'd use standard TCP sockets - this will survive all sorts of moving of components, and minimize configuration issues IMHO.