i'm trying to get computer's state in my LAN...
thought about using QTcpSocket but it's not realy effective since port also should be inserted as:
socket->connectToHost("hostName", portNumber);
if (socket->waitForConnected(1000))
qDebug("Connected!");
can anyone demonstare me a better way to check if computer is responding ?
ping
int exitCode = QProcess::execute("ping", QStringList() << "-c1" << "hostname");
if (0 == exitCode) {
// it's alive
} else {
// it's dead
}
Arguments may vary. For example, I believe it would be ping -n 1 "hostname" on Windows. The example should work on most non-Windows versions.
Are you trying to check if your local machine is on the network or if a target machine is ?
There isn't a good cross platform way of doing this.
The nearest on qt is QNetworkInterface, and check attribute "ISup" - it's not perfect, it may be active if you have a network cable connected but just to a router, and inactive if you have a 3G modem but aren't on a call.
On Windows check InternetGetConnectedState()
One good way is just to verify that they can resolve domain names using QHostInfo. If they can then they likely have internet access:
QHostInfo::lookupHost("www.kde.org", this, SLOT(lookedUp(QHostInfo)));
Of course, you could just try to connect to the host as well, which is even better proof that everything is working correctly. I would do it asynchronously rather than synchronously, but it's truly the best test.
Related
This summer I am working at a computer summer camp. All the kids love playing slither.io
The kids really want to play on the same world but slither.io doesn't provide an easy way to do this and instead spreads them out through the multiple servers. I have limited networking knowledge but am somewhat familiar to working with webSockets.
What I was hoping I could do to get them on the same world was:
Have one kid connect to slither.io and enter a game.
Once they were in open the dev tools in Chrome and get the ip and port that they were connected to with bso.ip and bso.po
The other kids could then using the dev tools run
connect("ws:\\123.123.123.123:444")
with the ip and port set to whatever the first kid had.
Running connect gets them into slither.io but 90% of the time it is on a different server/ip address
Is there a way to get them all in the same world?
Connecting to the WebSocket alone is not enough to register the game to use it. Looking at the source code, there is a function forceServer, which sets the IP and Port:
function forceServer (a, b) {
sos = [];
forcing = true;
bso = {};
bso.ip = a;
bso.po = b;
bso.ac = 999;
sos.push(bso);
}
The sos array is global and used later on to connect to the WebSocket and register the game instance. The exact details are difficult to follow because it's all minified in game73gig.js, but I think this function sets everything up.
Run the following in the Console instead:
forceServer("123.123.123.123", "443");
There is a Tampermonkey snippet to inject a form element and JavaScript to do this automatically. I haven't tried it but it's called Slitherio-Plugin.
I have a application I wrote that uses a serial port (hand scanner connected to it) and I need to detect somehow that another user switched so I can close that port and when the new user logs on to the application it wont get 'port in use' error. Any suggestions? My program is in VB.Net but open to any suggestions.
This is a common issue unfortunately.
I find the best thing to do is create a Windows Service to handle all of the comms so that it works independently of any user being logged in. You can use a WCF/Web Service to get data out of the Windows Service.
I hope this helps.
(I would have posted this as a comment instead of an answer if I could)
my problem is :
after set AT+CMGF = 1 ( for Text mode SMS), everything work well until GSM modem reboot
After reboot, AT+CMGF? command return 0 , this means modem need re-config for CMGF parameter.
Please help to save the config value even after reboot.
Thanks so much.
The traditional modem way to store configuration settings is through profiles, controlled with AT command AT&W, see my answer for some details about that command. Now if your particular modem supports more than one profile and if the AT+CMGF mode is included is another question, but at least AT&W is what I would start investigating around.
Is it possible to connect to a Air app running on another machine via socket(assuming we know ip) or some other mechanism(which doesnt use Cirrus/stratus)? If it is can someone please help me on how?
Let me rephrase question, I dont want to connect to a server over socket. I would like to know if it is possible to connect from one AIR app on machine A to connect to another AIR app on machine B via sockets without cirrus. I'm not asking for someone else to do my work, I couldnt find any documentation or possibility of the above thing. My conclusion now is that it is not possible, but I would just like it to be verified by other people(experts).
Absolutely, as3 supports sockets. http://www.ultrashock.com/forum/viewthread/81676/
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/Socket.html?filter_flash=cs5&filter_flashplayer=10.2&filter_air=2.6
There are two ways to do it. One AIR app can act as a server by creating a ServerSocket object while the other app connects to this with the Socket class. The other way is to use the DatagramSocket class.
In both cases, the trick is that because of network access translation, the IP address to use is not always easily discoverable unless at least one of the computers has a static IP. If both computers are on the same network subnet you can look up the IP address needed to reach one computer from the other manually. Otherwise, the IP one computer must use to reach the other won't be the same IP that the computer sees for itself. This matchmaking is the service that stratus/cirrus provides.
See http://www.brynosaurus.com/pub/net/p2pnat/ for a description of the problem.
A bit of history: We have an application, which was originally written many years ago (1998 is the first date in PVCS but the app is about 5 years older than that as it originally was a DOS program). This application communicates with a piece of hardware via serial. When we got to Windows XP we started receiving reports of the app dying after a short time of running. It seems that the serial comms just 'died' and the app was left in a stuck state. The only way to recover from this situation was to restart the application.
The only information I can find regarding this problem was apparently the Windows Message system would miss that information was received, the buffer would fill and the system would get stuck. This snippet of information was left in a old word document, but there's no evidence to back this up. It also mentions that this is only prevalent at high baud rates (115200+).
The solution was to provide customers with USB->Serial converters along with the hardware.
Today: We are working on a new version of the hardware that will run across a network as well as serial ports. So to allow me to work on the network code, minus the actual hardware we are using a VSCOM NetCom113 device. It also installs a virtual comm port on the users (ie: mine) machine.
Now I have got the network code integrated with the app, it appears that the NetCom device exhibits the same behaviour as a physical commport. This is undesirable as I need the app to run longer than ~30 seconds.
Google turns up zero problems that we experience.
I was wondering:
Has anyone experienced this before? If so what did you do to fix/workaround the problem?
Does anyone have any suggestions as to whether the original author of the document is correct and what I can do to test the theory?
Unfortunately I can't post code as the serial code is tightly couple with the rest of the system, though if you have questions regarding it I can answer questions about it.
Updates:
The code is written using Win32 Comm routines - so I am using CreateFile, ReadFile. There's also judicious calls to GetOverlappedResult.
It's not hanging per se, it's just that the comms stops. You can access the menus, click the buttons, but nothing can interact with the connected hardware. Using realterm you can see that no data is coming in or going out.
I think the reference to the windows message is that the problem is internal to windows. Data has arrived but the kernal has missed it and thus not told the rest of the system about it.
Flow control is not used.
Writing a 'simple' test is difficult due the the fact that the code is tightly coupled and the underlying protocol is quite complex and would require a lot of work.
Are you using DOS-style serial code, or the Win32 CreateFile approach?
If the former, be very suspicious: if at all possible I'd convert to the latter.
If the latter, do you know on what kind of system call it's hanging? Are you in a blocking read call? or an overlapped I/O call? or waiting on an event? (I'm not sure I have enough experience to help, but those are the kinds of questions that come to mind)
You might also check into the queue size, which you can set with the SetupComm function.
I don't buy the "Windows Message system" stuff -- it sounds fishy; you can write good Win32 serial i/o code that never uses Windows messages.
edit: does your Overlapped I/O use events? I seem to remember something about auto-reset events occasionally missing their trigger... check your overlapped I/O calls very carefully to see whether you're handling the possible outcomes properly. Perhaps there's a way to make your code more robust by automatically cancelling the overlapped i/o and restarting another read. (I assume the problem is in the read half, not the write half?)
edit 2: A suggestion: assuming the win32 side has missed a byte or packet, and your devices are in deadlock because they're both expecting each other to respond to something, can you tweak the other side of the serial I/O to regularly send some type of "ping" packet with an incrementing counter? (and log the ping packets on the PC side; that way you can see whether you've missed any)
Are you sure you have your flow control set up correctly? DTR, RTS, etc...
-Adam
i have written apps that use usb / bluetooth serial ports and have never had an issue. with bluetooth i have seen bit rates (sustained) of 800,000 bps for long periods of time. most people don't properly implement the port.
My serial port
Not sure if this is a possibility for you, but if you could re-write the code using C#.NET you'd have access to the SerialPort class there. It might remedy your problem. I know a lot of legacy code based around the Win32 API for hardware I/O ports tended to fail in XP due to timing (had a small bit of experience with MIDI).
In addition, I don't know if you can use the Win32 method of Serial Port access in Vista, so that might shut out future MS OSes from being able to use your code.