I have a windows service running in a production environment that I need to perform some diagnostic work on. The service listens on a specified port, receives and processes a TCP request, and issues a TCP response.
What I'd like to do is intercept this request and response so I can log it to a database. However I cannot recompile the code and need to make as few changes to the server as possible.
I seem to recall a past instance where a colleague was able to create an interceptor DLL and drop this into the root folder of a WCF or Web API service in order to accomplish a similar task. Would it be possible to accomplish something like that with this TCP service?
As long as the app uses System.Net.Socket, you can use the built in .net network tracing via app.config, docs from Microsoft here.
Adding source System.Net.Socket and System.Net with maxdatasize 1024 will cause it to log the first 1024 bytes of each send and receive.
Related
I am currently working on an Owin self-hosted web service that runs on my machine and that allows peers (other machines) to download files from its virtual directory with microsoft's BITS. The downloads will work with relatively small files, but whenever I have to download large files (over 2Go) I get this error from BITS:
"The server does not support the necessary HTTP protocol. Background
Intelligent Transfer Service (BITS) requires that the server support
the Range protocol header."
I was wondering if there was a way to enable the Range Requests in Owin or if I have to implement manually the "data chunking" in the requests I receive. Because changing the content of every request to have the header "Accept-Ranges: bytes" doesn't seem to work (I assumed it would not magically worked, but I tried it anyway).
I couldn't find a lot of information on what I am trying to do besides finding out how to know if a server is supporting the range requests.
There was this question that seemed to look similar to mine, but was more focussed on setting the headers properly. It doesn't really show if/how the code splits the file before returning the response. There was also something about IIS, but my web service doesn't run on IIS, it runs on the client's machine and is instanciated by a windows service.
I found a solution to my problem. With a little bit more research on the subject, I discovered this article which sums up really well the problem I had, which is that requests going trough ASP.NET Http Handlers do not support Range-specific requests. So I will have to manually implement support for the range specific requests in my web service.
I have a .NET service with a WCF host that uses Nlog for logging. I also have a WPF client that acts as a WCF client for the .NET service. The .NET services logs all message to a file (for now).
I want to use the client to output the current logged messages (ie, if a logging occurs while the client is open, then it'll be showed in a textbox for instance). If the client is closed, I don't need to see the messages.
I've thought of several ideas, but I'm not sure how good they are:
I could set up another host on the client that can receives messages from the Service.
MSMQ (with or without WCF), but then I think it'll just keep adding messages, which I don't want.
I could just open the Logfile itself, but I don't know which one will be the active logfile (seeing as this is handled by Nlog)
Are there any other ideas? Is there a better way for such communication between a (Windows) service and a client?
You might want to look into SignalR. Here's an example that does something like what you are after to display WF tracking records in a browser: http://blog.petegoo.com/2011/10/02/workflow-service-tracking-viewer/.
I have the following architecture for a project I'm working on.
My question is how to begin implementing the TCP/IP responder part.
It's function, in case the diagram is hard to read, is to wait for a connection from the Order Viewing client, and subsequently notify said client of incoming orders.
I was thinking a queue, but unfortunately I don't know where something like this would fit in the VS2008 hierarchy of things.
If it's part of the ASP.NET web page, should I use the application start event to start the TCP IP responder?
It's not a web service, because those respond to http requests...
If I had to implement your "TCP responder" I'd probably implement it as a windows service and have both the ASP.NET app and the Winform client contact it (e.g. to avoid the problem of recycling of the ASP.NET etc.)
That said, I can think of gazillion easier ways to get the effect you want to achieve (getting the winform client to know about new orders) such as
Using Queues as you mentioned. Windows comes with MSMQ (you need to enable it in add windows features). Using MSMQ from C# is fairly easy. You can also use WCF if you like
exposing an http endpoint on the client and have the client notify the ASP.NET server where it is listening by calling one of its pages
write the orders to the DB and poll it from the client/use System.Data.SqlClient.SqlDependency to know when there's a change
Heck even writing the orders to a file on a shared folder with a FileSystemWatcher would work (though I'd probably wouldn't recommend that)
Why don't you use http? You already have the http server so you don't need any TCP responder - just do http polling at the client.
And if you don't want polling or have too many clients then you can use something like SignalR for notifications.
I've written a client/server model in C# using .Net remoting. If I have the client connected to the server, then kill the server and restart it without trying to call any server methods from the client whilst the server is down, I can reconnect happily.
If I close the server then try to ping the server from the client (which I do from a separate thread to avoid an endless wait) then when the server comes back online, the client can never talk to it and my Ping thread that was fired during the downtime waits forever deep in the guts of the remoting libraries. I try to Abort this (if trying to Join the thread fails after a short time) but it won't abort. I'm wondering if this is part of the problem.
If I start up another client, then that client can talk to the server just fine. I figured I needed to restart some aspect of the original client but cannot see what would need to be shut down. I certainly null the server I'm connected to and call Activator.GetObject with the same address (something the second client does to connect to the server, which works fine), but re-getting the server doesn't help at all.
The server is running a as singleton via RegisterWellKnownServiceType.
I would start with wireshark and use it to see what is really going across the wire.
Is .NET remoting a requirement, or could you consider moving to WCF instead? The protocols are better factored and more clearly exposed when needed.
I was solving a similar problem. I had a working .NET remoting application using configuration files for the remoting and the routines of the .NET remoting I had to integrate into a larger application. I integrated this into the larger project, by the Activator.GetObject returned an instance of the proxy. As soon as there was a call of a member from the proxy instance, it ended up inside the member call and could not get off. The larger application contained various configuration files already thus the .NET remoting configurations I placed right there along with another configs for another thihs, and there was the crux of the matter. After I placed the .NET remoting configurations into a new empty config(s) file, the .NET remoting in the larger application started to work.
I have a project where I have created web service proxy classes with wsdl.exe and then simply create an instance of that class (inherits System.Web.Services.Protocols.SoapHttpClientProtocol) and call the method that should send a SOAP message. I'm using Visual Studio 2008 if that matters. And I'm trying this in my development machine without access to actual web service that is located inside of customer's intranet. So, the sending will of course not succeed and I will not get any response back but all I would like to see is the exact content of SOAP messages this solution creates and tries to send. How do I see that?
Use fiddler.
Have a look at SOAPUI from eviware.com.
Its a free for personal use Java app. Among other things you can
set it up to run as a dummy test server. Just load up hte WSDL
and enter the dummy data.
In test server mode it will log your requests so you can see whats happening
inside the request message.
If you're Web service is accessed by clear text, non-SSL HTTP, you can just use a sniffer, like Wireshark, to see the data coming from and to your application. Wireshark can trace, filter and analyze wire data. I have used it do debug HTTP and other protocols many times, and it's a great tool to do this.
SOAP messages are simply XML data sent using the HTTP POST method. So you can for example install a local web server on your development machine, configure your web service to use some dummy URI on this server, and grab the network traffic with WireShark (AKA ethereal). The big advantage of this method is that it involves no coding.
Alternatively you can use an HTTP echo server that dumps its incoming traffic, like this one (found while googling "http echo server"):
You can intercept the call with tcpMon