I have an application which is running on a remote machine. The only contact with the application is through a webservice, i can send it a command to shut down - but how do i start it again? I would like to have a scheduling type of service where i have a windows service on my machine and at 08:00 am it sends a startup command through the webservice(??) and at 04:00 pm it sends a shutdown command through the webservice. The shutdown i can do, but the wake on lan thing - because its not a lan, its potentionally the internet - any suggestions?
cheers,
You won't be able to wake your remote machine up using a web service call to your actual machine you want to wake up. You will have to send it a 'magic' packet.
Luckily there are a bunch of tools and utilities out there that allow you to do this quite easily.
Check out wolcmd.exe - that should do the trick for you.
Equally, there's nothing stopping you rolling your own client that sends the magic packet, if you are so inclined.
And if you want to run this from a web service (not located on the target machine obviously), you simply wrap wolcmd.exe by using System.Diagnostics.Process.Start().
Here are two links that I googled on here and here. My take is that you'd need to connect to a remote lan via VPN passing through a firewall to be on the same subnet and similar ip address as where the webservice is running on! That should be secure enough and if you do that, only your machine can then be shut down remotely. My feeling is this - you'd need to be connected directly to the remote endpoint all the time...But at the top of my head, that sounds frankly impossible, as how will the remote endpoint know your ip address if your machine went to sleep...You need to be careful of certain drivers that will refuse to go to sleep and therefore preventing your machine from going to sleep. I happen to have a 3G mobile broadband, and my netbook refuses to sleep unless I shutdown the connection and unplug it (even if its still plugged in, it refuses to sleep!), the reason I say that, if you were to use VPN, and it went to sleep, then that connection is lost - that's my opinion of it. What do you think?
Hope this helps,
Best regards,
Tom.
If the web service is on a separate box on the same local LAN as the box which needs to be started, it should be possible to have a web service use Wake-on-LAN technology to start it.
Related
I connected two laptops together with a wi-fi modem.
Laptop1 got the IP 192.168.0.20
Laptop2 got the IP 192.168.0.21
I launched an ASP.Net Core web application on Laptop2 on port 44382.
I turned off both laptops' firewalls.
The result of ping 192.168.0.20 from laptop2
The result of ping 192.168.0.21 from laptop1
When I call my API from the laptop2(localhost) there is no problem and I see the result
The problem is when I call API from laptop1(another laptop), after a long time I see this
I can't find what my problem is.
You're most likely using IIS Express, which doesn't automatically bind everything the way you need for remote access. This answer breaks down what you'll need to accomplish that fairly well, but you may just want to look at installing IIS.
Make sure door 44382 is open in the firewall.
Create new rule in/out for port here (advanced configs of firewall)
Please excuse my lack of experience, I'm not sure where to begin, I'm googling my self in circles.
Would it be possible to create a socket server (c#) console application and host it on a goDaddy shared hosting account. I'm trying to create a server/client application but I'm stuck with a shared hosting account from goDaddy.
Also, is there a significant difference between sockets and webSockets?
If you could point me in the right direction, or at the very least let me know if its even possible...?
EDIT:
I have a WPF application running of a windows surface tablets (3 tablets), the application is for time tracking, it gives people the ability to login / logout using an RFID reader. For the backend I'm using Web API and the issue is latency. It sometimes takes up to 15 seconds for the application to create a connection, authenticate (if not authenticated) and get the person's status.
Needless to say staff are impatient and I see their point (they should be able to swipe, confirm and walk away), I'd like to be under 2 seconds max. So I figured if I can keep a connection open through-out operating hours (sockets), then fetching a user's status should be near instantaneous.
I'm open to any suggestion/recommendation. I can't thank you enough! Thnx a million!
Without getting into some rather hinkey maneuvers that would probably get your account shut down you would be very hard pressed to run a socket server on godaddy shared hosting. Mechanically you'd need to be able to execute a custom .exe which would need to be executed -- and kept executing -- by something somewhere. This executable would also need to listen on a particular TCP port which would most likely be either in use like ports 80 and 443 or would likely be firewalled from the rest of the world.
Hosting a web socket app would be tricky -- first they would need to have ugraded to IIS 8 and cursory tests indicate they are still on IIS 7.5. Second, they would need to permit websocket usage which is not something likely to be enabled on shared hosts. I think resource usage would be a challenge if you managed to run these two traps.
It would help quite a bit to understand what you are doing but if it is something that requires either sockets or even web sockets you are looking at a class of hosting above the godaddy shared options.
I have a .Net service that runs on a local network computer. On my Android phone I have to discover the server as fast as possible and get data from it.
I have considered these options so far:
Scan each address and check if they respond - it takes about 30 seconds - NOT VIABLE
Use the broadcast address to send pings - default Windows settings disable the ICMP ping, so it is unreliable - NOT VIABLE
Use UPnp - Android discovery client is available, .Net device host not available, COM and ATL are way too hard to implement (no documentation, only interface guidelines - and it is mosty used by routers and NAS) - NOT VIABLE
What else should I try?
Here is how I've eventually done it:
The .Net service runs an UDP listener on a separate thread
The Android client sends an UDP broadcast signal and waits for response
If the response contains a specific message, it means a proper server
Using this approach, it works very quickly, takes 1-2 seconds to discover the servers.
I wrote a small daemon application in .NET last year that basically launches a Minecraft server, and provides a web based GUI to manage it. It does other things such as restart the process if it crashes, and other useful functions.
Our company recently heard of a french hosting company that had setup their servers in a way that when the last player disconnected, the server would shutdown until another player joined. Now, I have been thinking about how this might be possible, and wanted to see what the thoughts on it were. My daemon can already tell how many players are connected, so that is not an issue.
My psuedo thought process is...
Last Player disconnects from server
Daemon takes over listening on the server port for connections
Upon incoming connection, save the connection packet data and restart the server sub-process
Pass the save connection on to the Minecraft java process
I can't really figure out how to handle the last step yet, but that is the best solution I have come up with. Any thoughts or suggestions?
Perhaps you'll have more players wanting to connect at once, so you might have problems with that approach (cuz i'm guessing your server won't start instantaneously).
You should have a daemon waiting for connections and putting them on a queue or something, until the server starts, and feed it then, the connections (or connection packets or whatever). After the server is started, and all connections have been forwarded to it, get your daemon to "stop" (a.k.a die or stop clogging the port)
Hope this helps.
You can not "save" a TCP network connection and then redirect it to a different process. The only way to implement this would be to let your tool act as a proxy server that accepts all connections and sends all data to the server running on a different port.
In such a set-up you could start the server upon the first incoming connection.
The only other solution would require direct read access to the network interface the way e.g. is used by Wireshark/Pcap library. They you would be able to detect TCP SYN packets and start the server when they are coming in.
I need to "discover" local computers running my windows WCF service, so I can talk to them. Right now you have to enter manually the ipaddress:port combination, but I would like to have a (web?) application that monitors the machines running the service and reports on it.
When I try to connect to an invalid ip/port it takes "forever" to timeout, so it's not feasible to check all the ip on my local network. Is there a quick way to discover which machines have the port open (all of them have the hole in the firewall for that specific port)
TIA
I have done this several time. Just set the timeout value very low.
ALso if its a real machine but without the port open it should fail fast anyway. If you are doing a subnet sweep then, yes, you need to have a (say) 1 second timeout.
Multi-thread the sweep - this is a fun thing to code
edit: I cant find my code. here is link to solution from somebody else
http://social.msdn.microsoft.com/forums/en-US/netfxnetcom/thread/c8161442-61b5-4840-999b-5bb36bda0b6d/
could you have the client configured to contact the web app and report with it's location that it is running your wcf service?
that would require the web app to be running on a known machine that doesnt change.
Why not make them use multicast to broadcast a "HELLO" packet every so often. This is assuming of course that multicast is available in your scenario and your not talking across routing domains. Simply use the "HELLO" packet contents such as ipv4 unicast address to ensure you know what you should be talking to. Of course you don't need to use multicast, you can just send a broadcast to 255.255.255.255 which is not a complex task and then listen for these messages. The benefit of this is that you could also enable negotiation of the port. For instance, if your application generally binds to a port but this port is unavailable, it can automatically choose a port and let you know what port it is bound to. Avoids manual configuration maintenance and headaches involved. Hell, it can even use broadcast to send a message and check if it received it. If it doesn't, fire off an alert letting the systems administrator know.
I use something along these lines for managing test harnesses for soft switches (voice) and it works very well.
Of course, I could be very much off on this. Just thinking out off the box here.