What is the best way to access a running mono application via the command line (Linux/Unix)?
Example: a mono server application is running and I want to send commands to it using the command line in the lightest/fastest way possible, causing the server to send back a response (e.g. to stdout).
I would say make a small, simple controller program that takes in your required command line arguments and uses remoting to send the messages to the running daemon.
This would be similar to the tray icon controller program talking to the background service that is prevalent in most Windows service patterns.
Mono's gsharp tool is a graphical REPL that lets you Attach to Process.
#Rich B: This is definately a suitable solution, which I already had implemented - however on the server I have to use, the remoting approach takes around 350ms for a single request.
I've measured the time on the server side of the request handling - the request is handled in less than 10ms, so it has to be the starting of the client program and the tcp connection, that takes up the time.
Hence the hope that I can find another way to post the requests to the server application.
You can use the system.net.sockets abstractions to create a service on a TCP port, and then telnet to that port.
Check the library status page; Mono's coverage here is a bit patchy.
Related
I have one Batch job on one server which is intern calling the service on the other server.
The issue is-(we suspect)the batch job is unable to call the service,but we are not very sure.
How to ensure that service is not getting called from the network point of view.
we checked telnet between the two servers which is fine.
Is this the only way to troubleshoot?
note: we can not do the code level changes now.
You could make use of tools like wireshark or
tcpdump to capture the network traffic and see that your script is indeed sending o/g requests.
I have an application that I inherited that listens on port 7001 for UDP broadcasts from our in-house test equipment, and I recently updated another application that needs to do the same thing. Both applications must be able to coexist on the same computer.
Currently, when my recently updated application attempts to bind to the port to listen for UDP broadcasts and fails, it simply reports that the port is not available and suggests that the inherited application is probably running. How can I get my application to detect what application is actually listening on that port? I've done a Google search and have even searched this site, but so far I have been unable to find anything except to use Task Manager, TCPView, or netstat at the command line.
I would prefer a technique that either uses the Windows API or a Windows system COM component, since both applications are written in Visual Basic 6.0. (I know, I know, but I must maintain these applications since they are mission critical.) However, a .NET solution would would also be useful in case I need it in my new development efforts.
Use:
netstat -n -o
That will show the process ID and from there you can either look in the Task Manager's process viewer, go to menu View → Columns... and check the Process ID (PID). Then you can see the name of the process listening on that port.
Of course, you're wanting a programmatic way of accomplishing this and the GetTCPTable2 API is best as was already suggested. In fact, if you look at the IAT (Import Address Table) for netstat.exe, it actually uses that API to get that information.
There is a way to communicate directly with a command window and get its output using pipes and it would work fine, but the ideal way is to simply use the same API netstat uses.
I am currently using Remote Method Invocation to interact with a windows service. As services cannot be interactive (UI) strictly from Vista and above, I cannot directly call those methods. So I am using Remote Method Invocation to access those methods. How safe is RMI?
Are there any better alternatives to using RMI? Like File channeling/ sockets and Listeners.
edit: Let me make it clear,
I have a java application which runs as a windows service. But I would like to manipulate the service and the way it works from an user interface but When I try to do that, Windows wont allow me to do that. So I am using RMI to manipulate the windows service from an user interface.(interactively).
Keep in mind that there is a reason for windows services not being able to have an UI. If you need an UI to interact with the service, what's the reason for running the program to interact with as a service anyway?
That being said, I'm using RMI to interact with the service (simply to do some configuration, poll status information; the program being executed as a service usually runs without any user interaction) - it's worked out pretty well so far.
You could of course use simple sockets (however, RMI is also built on sockets). A simple Listener won't work since you'll need some inter process communication.
For example http://www.utorrent.com/testport?port=12345
How does this work? Can the server side script attempt to open a socket?
There are many ways of accomplishing this through server-side scripting. As #Oded mentioned, most server-side handlers are capable of initiating socket connections on arbitrary ports, and most of those even have dedicated port-scanning packages/libraries (PHP has one in the PEAR repository, Python's 'socket' module makes this type of tasks a breeze, etc...)
Keep in mind that on shared host platforms, socket connections are typically disabled for security purposes.
Another way that is also very easy to accomplish is to use a command-line port-scanner such as nmap from your server-side script. i.e in PHP, you would do echo ``nmap -p $port $ip\
The server side script will try to open a connection on the specified port to the originating IP.
If there is no response (the attempt will timeout), this would be an indication that the port is not open.
The server can try, as #Oded said. But that doesn't ensure the receiver will respond.
Typically, something like this happens:
The URL request contains instructions about which port to access. The headers that your browser sends include information about where the request is originating from.
Before responding to the request, the server tries to open a port and checks if this is successful. It waits a while before timing out.
The webpage is rendered dynamically based on the results of this test.
The response is returned to you containing the results.
Sometimes steps (2) and (3) will be replaced with an AJAX callback, which allows the response to return sooner.
I have a server and client program on the same machine. The server is part of an application- it can start and stop arbitrarily. When the server is up, I want the client to connect to the server's listening socket. There are win32 functions to wait on file system changes (ReadDirectoryChangesW) and registry changes (RegNotifyChangeKeyValue)- is there anything similar for network changes? I'd rather not have the client constantly polling.
There is no such Win32 API, however this can be easily accomplished by using an event. The client would wait on that event to be signaled. The server would signal the event when it starts up.
The related API that you will need to use is CreateEvent, OpenEvent, SetEvent, ResetEvent and WaitForSingleObject.
If your server will run as a service, then for Vista and up it will run in session 0 isolation. That means you will need to use an event with a name prefixed with "Global\".
You probably do have a good reason for needing this, but before you implement this please consider:
Is there some reason you need a connect right away? I see this as a non issue because if you perform an action in the client, you can at that point make a new server connection.
Is the server starting and stopping more frequently than the client? You could switch roles of who listens/connects
Consider using some form of Windows synchronization, such as semaphore. The client can wait on the synchronization primitive and the server can signal it when it starts up.
Personally I'd use a UDP broadcast from the server and have the "client" listening for it. The server could broadcast a UDP packet every X period whilst running and when the client gets one, if it's not already connected, it could connect.
This has the advantage that you can move the client onto a different machine without any issues (and since the main connection from client to server is sockets already it would be a pity to tie the client and server to the same machine simply because you selected a local IPC method for the initial bootstrap).