Is there any way I can determine which netNamedpipe channels are currently open? This will help me debug my WCF Client/Server and make sure I am closing my channels properly.
This is similar to the netstat tool for network connections, but for netNamedPipes instead.
There is no tool to do this, as far as I am aware.
You can use Process Explorer to find what handles to named pipe objects a process is holding, but this will not really answer your question. To recognise pipes which are created for WCF NetNamedPipeBinding channels you need to know what you are looking for. WCF pipes will incorporate a GUID in their name, looking something like this:
\\.\pipe\197ad019-6e5f-48cb-8f88-02ae11dfd8c0
See here for more on this.
However, the fact that a handle exists doesn't per se tell you anything about the state of the channel. There is a WCF pooling mechanism for pipe connections, so even if the channel is properly closed this does not guarantee that the pipe connection itself has been dropped and the handle released (though if you were to see a process gradually acquiring more and more handles that would suggest there might be a problem with channel cleanup).
If you want to confirm that channels are being cleaned-up promptly I would suggest you enable WCF Tracing in verbose mode: this will tell you exactly what is going on.
You can use Process Explorer to see what pipes a process has open:
http://technet.microsoft.com/en-us/sysinternals/bb896653
SysInternals has a command called PipeList. I believe you can download the command separately here:
http://technet.microsoft.com/en-us/sysinternals/dd581625
Related
I am currently writing a system logging program which sends different logs via ftp.
The Problem I am facing is that my program should constantly check if the connection is being used before and during it's upload in order to stop sending packets if a different program wants to use the connection.
I actually found this link helping me measure the speed of the connection, but I think I can only use the latter in order to discover if the something is already being streamed.
After reading the library entry on System.Net.NetworkInformation, checking various Network Statistics and states wasn't a problem either. As stated beforehand my only problem is checking if some other program wants to send something.
As you can probably tell from the question, I am very new to this topic and a fairly junior programmer. I have been reading up on the System.Net.NetworkInformation Namespace library and facilitating it's various classes, methods and delegates. I have the feeling that I am on the right track, but just not getting there. Anyone got a push in the right direction?
Thank you.
I ended up using the System.Net.NetworkInformation library and it's methods.
The methods GetIsNetworkAvailable(), NetworkChange.NetworkAvailabilityChanged Eventhandler and the TcpStatistics helped me gather information on the connection. MSDN and the reference is a great guide in using the foregone mentionend methods and I basically used the examples with slight modifications to suit my needs.
msdn NetworkInformation:
http://msdn.microsoft.com/de-de/library/system.net.networkinformation.aspx
The GetIsNetworkAvailable is pretty straight forward returns boolean value on connection being up or down.
Networkchange.NetworkAvailabilityChanged triggers an event on connection loss or reconnection. See the msdn link above for an excellent and very usuable example on it's usage.
And the TcpStatistics return information on how many connections have been accepted, initiated, errors received, failed connections, connection resets and more. These were the five I used so far to evaluate the connection.
I realized that you do not really need any more to monitor the connection efficiently.
Maybe the method NetworkInterface.GetAllNetworkInterfaces() can help finding out which Networkadapter is sending the data and should be monitored.
I now understand the comments of Peter Ritchie to my question. FTP transmission runs extremely well and the protocol handles the transmission of the files flawlessly and no problems have arisen up until now in streaming the log files. In 4 weeks of testing I have received the logging data constantly.
I'm looking to write a custom program in VB.NET / C++ / C# that would allow me to monitor a system's vitals over a Remote Desktop Connection.
I'm only looking for tips on how to implement a connection like this in code (eg. is it just a simple object or call to a WScript function? or is it much more sophisticated?). As to the specifics of operation after making the connection, I have that figured out based on another program which shares some similar features.
I would definitely look on Google and self-teach this, but I don't even know where to begin / what to search for. Some advice into this would be amazing, thanks!
EDIT: This doesn't have to go through an RDP connection, I'm definitely looking for better ways. Reason I mention RDP is because I currently do this manually over an RDP connection, but I don't wanna have to constantly open the window.
I don't think the RDP protocol is the right solution for this. Other mechanisms were invented for this, such as WMI.
WMI is a scriptable interface that allows you to query the local or remote computer's information. You can use your tool of choice - C#, VBScript, or my personal preference - Powershell. Here is an example of how to get all of the processes on a remote machine.
EDIT:
This doesn't have to go through an RDP connection, I'm definitely looking for better ways. Reason I mention RDP is because I currently do this manually over an RDP connection, but I don't wanna have to constantly open the window.
Then ignore everything below the line. Really.
The RDP protocol is very specialized for sharing specific resources. Namely the screen, disks, clipboard, printer, ports, and sound. That's it for what's out-of-the-box. The best thing you could possibly do is occasionally monitor the contents of a file with the RDP protocol - and it is cumbersome and slow.
I'd encourage you to look at alternative solutions like WMI instead.
That said, it is possible to do this with RDP's support for Virtual Channels. You could create a scriptable virtual channel to accomplish this (which is no easy feat). You would have to write a client and server. Your server side functionality would report the information you are interested in monitoring, and the client side would receive it. Again, I would stress that this is not the correct solution.
I want to provide a direct connection between two instances of my program, which are located on two different computers.
I already have the means to obtain the IP addresses, but how do I make a connection between my programs and have no trouble with the firewall or ports?
I need to send serialized objects through the connection.
Edit2: The specific term is peer-to-peer connection.
Edit: I see I need to explain the "no trouble" part.
First, when a program attempts to communicate to the internet, the annoying Windows Firewall permission dialog opens.
On Windows 7, you have two checkboxes:
1. Allow on private (home/work) networks, which is checked by default and, sometimes, cannot be unchecked.
2. Allow on public networks, which is either checked or unchecked by default...
NO ONE I know makes sure that all the check boxes are checked. NO ONE.
This can interrupt the program sometimes in bad ways, without people knowing!
Next... Most people are behind a router and routers usually block all the requests to undefined ports, unless the rules are changed.
Nobody will accept to add these rules just to use a program. Nobody.
You can use WCF for this purpose.
It doesn't solve 'all' network problems though, but I doubt any technology would.
It kind of sounds like you're looking for a way to bypass firewalls so that your users won't have to deal with that kind of stuff while using your program.
If that's indeed the case, think about it this way. Would the Windows Firewall be good at its job if it allowed you (or anyone else) to do that?
What you might want to do is open up a port using TCP and send serialized objects over it to a target listener, which knows how to decode those bits back to objects.
If you need that port open, your users will have to allow that. If they're running a firewall that blocks it, then that firewall needs to be properly configured to allow your program to interact with the target computer.
You can use TcpClient, TcpListener (System.Net) and BinaryFormatter (System.Runtime.Serialization) to send serialized objects over TCP.
Remember you need to specify your custom classes as [Serializable].
So, using a TcpClient and a TcpListener works... as long as I forward the ports on the listener's router.
So this is not an option.
I ended up using my database to queue commands and check for them every once in a while, and dequeue them when necessary.
For the moment, I cannot find any good answer.
I'm working with an application, and I am able to make C# scripts to run in this environment. I can import DLLs of any kind into this environment. My problem is that I'd like to enable communication between these scripts. As the environment is controlled and I have no access to the source code of the application, I'm at a loss as to how to do this.
Things I've tried:
File I/O: Just writing the messages that I would like each to read in .txt files and having the other read it. Problem is that I need this scripts to run quite quickly and that took up too much time.
nServiceBus: I tried this, but I just couldn't get it to work in the environment that I'm dealing with. I'm not saying it can't be done, just that I can't get it done.
Does anyone know of a simple way to do this, that is also pretty fast?
Your method of interprocess communication should depend on how important it is that each message get processed.
For instance, if process A tells process B to, say, send an email to your IT staff saying that a server is down, it's pretty important.
If however you're streaming audio, individual messages (packets) aren't critical to the performance of the app, and can be dropped.
If the former, you should consider using persistent storage such as a database to store messages, and let each process poll the database to retrieve its own messages. In this way, if a process is terminated or loses communication with the other processes temporarily, it will be able to retrieve whatever messages it has missed when it starts up again.
The answer is simple;
Since you can import any DLL into the script you may create a custom DLL that will implement communication between the processes in any way you desire: shared memory, named pipe, TCP/UDP.
You could use a form of Interprocess Communication, even within the same process. Treat your scripts as separate processes, and communicate that way.
Named pipes could be a good option in this situation. They are very fast, and fairly easy to use in .NET 3.5.
Alternatively, if the scripts are loaded into a single AppDomain, you could use a static class or singleton as a communication service. However, if the scripts get loaded in isolation, this may not be possible.
Well, not knowing the details of your environment, there is not much I can really offer. You are using the term "C# scripts"...I am not exactly sure what that means, as C# is generally a compiled language.
If you are using normal C#, have you looked into WCF with Named Pipes? If your assemblies are running on the same physical machine, you should be able to easily and quickly create some WCF services hosted with the Named Pipe binding. Named pipes provide a simple, efficient, and quick message transfer mechanism in a local context. WCF itself is pretty easy to use, and is a native component of the .NET framework.
Since you already have the File I/O in place you might get enough speed by placing it on a RAM disk. If you are polling for changes today a FileSystemWatcher could help to get your communication more responsive.
You can use PipeStream. Which are fast than disk IO as they are done using main memory.
XMPP/Jabber is another appraoch take a look at jabber.net.
Another easy way is to open a TCP Socket on a predefined Port, connect to it from the other process and communicate that way.
I have two unrelated processes that use .NET assemblies as plugins. However, either process can be started/stopped at any time. I can't rely on a particular process being the server. In fact, there may be multiple copies running of one of the processes, but only one of the other.
I initially implemented a solution based off of this article. However, this requires the one implementing the server to be running before the client.
Whats the best way to implement some kind of notification to the server when the client(s) were running first?
Using shared memory is tougher because you'll have to manage the size of the shared memory buffer (or just pre-allocate enough). You'll also have to manually manage the data structures that you put in there. Once you have it tested and working though, it will be easier to use and test because of its simplicity.
If you go the remoting route, you can use the IpcChannel instead of the TCP or HTTP channels for a single system communication using Named Pipes. http://msdn.microsoft.com/en-us/library/4b3scst2.aspx. The problem with this solution is that you'll need to come up with a registry type solution (either in shared memory or some other persistent store) that processes can register their endpoints with. That way, when you're looking for them, you can find a way to query for all the endpoints that are running on the system and you can find what you're looking for. The benefits of going with Remoting are that the serialization and method calling are all pretty straightforward. Also, if you decide to move to multiple machines on a network, you could just flip the switch to use the networking channels instead. The cons are that Remoting can get frustrating unless you clearly separate what are "Remote" calls from what are "Local" calls.
I don't know much about WCF, but that also might be worth looking into. Spider sense says that it probably has a more elegant solution to this problem... maybe.
Alternatively, you can create a "server" process that is separate from all the other processes and that gets launched (use a system Mutex to make sure more than one isn't launched) to act as a go-between and registration hub for all the other processes.
One more thing to look into the Publish-Subscribe model for events (Pub/Sub). This technique helps when you have a listener that is launched before the event source is available, but you don't want to wait to register for the event. The "server" process will handle the event registry to link up the publishers and subscribers.
Why not host the server and the client on both sides, and whoever comes up first gets to be the server? And if the server drops out, the client that is still active switches roles.
There are many ways to handle IPC (.net or not) and via a TCP/HTTP tunnel is one way...but can be a very bad choice (depending on circumstances and enviornment).
Shared memory and named pipes are two ways (and yes they can be done in .Net) that might be better solutions for you. There is also the IPC class in the .Net Framework...but I personally don't like them due to some AppDomain issues...
I agree with Garo.
Using a pub/sub service would be a great solution. This obviously means that this service would need to be up and running before either of the other two.
If you want to skip the pub/sub you can just implement the service in both applications with different end points. When either of the applications is launched it tries to access the other known object via the IPC proxy. If the proxy fails, the other object isn't up.
-Scott
I've spent 2 days meandering through all the options available for IPC while looking for a reliable, simple, and fast way to do full-duplex IPC. IPCLibrary, which I found on Codeplex.com, is so far working perfectly out of all the options that I tried. All with only 7 lines of code. :D If anyone stumbles across this trying to find a full-duplex IPC, save yourself a ton of time and give this library a try. Grab the source code, compile the data.dll and follow the examples given.
HTH,
Circ