I implemented the Bluetooth server according to the example shown in http://www.codeproject.com/Articles/252882/Bluetooth-Server-Programming-on-Windows.
I modified it a bit to use AF_BTH, SOCK_STREAM, BTHPROTO_RFCOMM.
It works fine.
However, if I restart the computer, the program hangs at accept().
If I then un-pair the two devices and then re-pair them again, the program works.
Any clues as to why this is happening.
So the program hangs on accept, from what I know accept in windows bluetooth sockets and other Bluetooth sockets platforms, accept like functions are a blocking asynchronous call, it pretty much block/freezes the thread that is on, and waits a client to connect, now winsock2 handles one thread operations much better than other platforms yes i'm looking to you android ,but still the program might get unstable if two of those calls occur , furthermore the guy only checks for one error in accept , so try referring to this complete list of winsock errors
(retrieved by winsockgetlasterror()) ,
also can you pls provide the client code and more info like on what platform, ide,devices , you are using ?
Related
I have a C++ program that uses Boost ASIO to communicate with a network device over a TCP socket. The program is working fine on Linux, but with Windows 7 I'm finding that the communication is not working very well. After some experimentation, I found that there's a 0.5-second delay between command and response when communicating with the device using the ASIO example telnet program, even though the response shows up in Wireshark much more quickly.
I gather that the problem is that the network device is not setting the PSH flag after it completes a chunk of data. See: http://smallvoid.com/article/winnt-tcp-push-flag.html.
I need to somehow set up my app so that it receives data from the TCP socket regardless of whether a packet has arrived with the PSH bit set. I know this must be possible because PuTTY can communicate with my device normally. I'd rather not use a registry key to get the effect, because I want to change the behavior only for this one socket, not the entire system.
What do I need to do to get Windows to ignore the PSH flag for this connection?
You could try specifying the MSG_PUSH_IMMEDIATE flag on the receiving side (https://msdn.microsoft.com/en-us/library/windows/desktop/ms741688(v=vs.85).aspx).
I'm trying to connect to a device on COM3 and the code runs until I call open("COM3"), which causes a stack overflow. Here's the relevant code:
asio::io_service io;
asio::basic_serial_port<asio::serial_port_service> scope(io);
//Open the connection and configure it
cout << "OPENING\n";
system::error_code error;
scope.open(PORT, error);
After opening the connection I configure it with the baud rate, etc.
It's hanging in win_iocp_serial_port_service.ipp, inside of SetCommState(handle, &dcb).
I also have some labview code to connect, send a command, and disconnect, which works. If I've run the labview code since starting up my computer, then my C++ program works (connects without hanging), but if I haven't yet run the labview code it gives me a stack overflow. This makes me think that I'm not starting up some driver or setting something persistent but I'm not sure what it would be.
If anyone's run into this issue or has any insight I appreciate the help!
Info from further testing: Connecting from non-labview serial connection clients seems to enable boost to connect as well. If I first connect via hyperterminal it works, and if I connect via command line (per this guide https://learn.sparkfun.com/tutorials/terminal-basics/command-line-windows-mac-linux) then I can subsequently connect via boost as well, which might be a workable solution, even if its dumb. Unfortunately I couldn't successfully send data with System.IO.Ports.SerialPort so the temporary solution is connect using System.IO.Ports.SerialPort, disconnect, then connect using boost asio now that it works. This works reasonably well but the code now only works on windows.
Since you can use your serial instrument from LabVIEW, your hypothesis that you're "not starting up some driver or setting something persistent" is probably correct.
You can see how LabVIEW and VISA are configuring the port and sending commands using a tool provided by NI called I/O Trace [1]. Once you have the working settings and commands in hand, you can match them with your calls to boost::asio and determine if you are over- or under-configuring the port.
In the I/O trace logs, you'll see VISA setting the baud, flow control, and the other traits before opening a session. The driver doesn't share much more than that, however, so if your program is using the same settings and sequence but still hanging, then scrutinize how you're programming to the asio interface [2].
References
[1] Performing a Good NI I/O Trace Capture for Debugging/Troubleshooting
http://digital.ni.com/public.nsf/allkb/282C5D41E2BA04F2862574BA007803B9
[2] Serial ports and C++
http://www.webalice.it/fede.tft/serial_port/serial_port.html
I use embedded hardware (by TI : Piccolo Control Stick xxx69) which uses FTDI usb to serial converter hardware.
On PC, I have simple VC++ application which tries to communicate to hardware over Virtual COM port (VCOM : typically COM7).
I am able to connect to port properly.
I am able to send data from application/PC to hardware and it is received correctly. (So, Tx on PC is working fine), Application first opens the connection using createfile(... ... ...) API and then uses writefile(.. ... ..) windows apis to write into the port directly.
SURPRISINGLY, I am not able to read from serial port to application. When I call readfile(... ... ...) api, it returns status as TRUE but ZERO bytes are read. I tried using API monitor software, which shows kernel api Ntreadfile(... ... ...), returns error as STATUS_TIMEOUT" [0x00000102]. It is surprising, because write works but read doesn't although data is there on line.
Data is on the line, because when I use normal hyper-terminal software, I am able to read the data correctly form controller and it is visible. [On controller side, it is all right because we can see data on hyper-terminal.
I am not windows programmer, as I deal with micro-controllers. Therefore, some help in terms to pursue this issue would be of great help.
Best Regards,
-Varun
Here is a Reference
Issue is solved. I had to add wait till InQueue > 0 (it means there is atleast 1 byte in receive buffer) or timeout (as safety exit) is over. it would be blocking call but it is OK for my application at the moment. waitComm() did not work well for me here.
sample snippet:
while(1)
{
ClearCommError((HANDLE)*h_drv, (LPDWORD)&Err, &CST);
if((CST.cbInQue >0)||(count >1000000))
break;
count++;
}
I am working on a client/server application (using qt for tcp).
The clients have to send about 15 messages per second to the server.
The problem is this:
the messages from the clients are received in groups. What i mean:
when i get the readyRead() signal and i read the data from the socket, there are multiple messages in the buffer.
This of-course causes lag in the system.
I tried putting the incoming connections in separate threads (thread per connection) but there was no improvement.
I also tried to rise a thread each time i got a readyRead() signal, but again nothing...
BUT when i run a number of clients on the same pc as the server, everything seems ok. When using different pc's over the network, the lag occurs...
(the network used is 100Mbps LAN, the messages are <200KB, and ping between pc's is <5msec, so i don't believe it's a network issue)
On the client side, the code to write the data is pretty simple:
tcpSocket->write(message.toUtf8());
tcpSocket->waitForBytesWritten();
tcpSocket->flush();
I also tried it without flush() or waitForBytesWritten() but the same...
EDIT: Using Qt 4.8.4 and Windows 7 and XP
Anybody has any idea how to overcome this?
Thank you in advance!
The last time I ran into a similar problem was with the stdin/stdout communication of a QProcess of Qt3.3. It behaved completely different on Linux and Windows.
Finally we found out that on Linux it used select() to react asynchronously when data arrived (fast, in most cases only one line readable) while on Windows the existence of new data was polled via a QTimer from the Qt mainloop (large delay, several messages available). A workaround we tried was to reduce the timer period in the source of Qt, but at the end we switched to shared memory based on the native OS mechanisms.
Your description sounds like you are using a similar Qt version on a Windows OS.
I'm writing program that should control a piece of scientific hardware over COM-port. The program itself is written in wxWidgets and uses ctb library. To test, it before I connect it to 300k€ equipment, I use com0com (Null-modem emulator) to forward COM2 port. To emulate my hardware I use wxTerminal (COM3). Altogether it works nice. One can debug not only in VS or DB but also see the whole data transfer in wxTerminal.
Now to my problem. I use to send data to COM-port ctb::SerialPort::Write() function.
device->Write( (char*)line.c_str(), line.size() );
However, if I disconnect the connection on the side of wxTerminal (i.e. COM2->NULL) than program hangs in this function.
It's obvious that I should add some function to test if my equipment is still there, but to do it I need to send data-packet to it and expect some answer. So I'm back to the Write().
"Just in case" I've also tried ctb::IOBase::Writev (char ∗ buf, size_t len, unsigned int timeout_in_ms) with timeout set to 100ms and I've still got program hanging in the same line. It's actually expected behavior as in this case timeout means only that the connection line is blocked till whole buffer is transferred or timeout is reached.
Connecting of wxTerminal to COM3 leads to un-freezing of debugger or stand-alone program. The Sun is shining, the birds are singing.
Can somebody give me a hint how to overcome my problem? I'd appreciate if comments would be restrained to wxWidgets-world - I really do not want to re-write whole program with other toolkit.
If you COM port library does not provide effective timeouts on write block, (presumably because of hardware flow-control), you could implement your own by threading off the write. You could use a couple of events/semaphores/condvar/whatever. One to signal to the thread that there is something in a buffer to send and another that you can wait on with a timeout that is signaled by the thread after it has sent the buffer. If the 'ack' wait times out, your COM port is stuck and you can pop up some 'Check cable' messageBox. I don't know what other calls your port lib supports, so I don't know how you could implement flushes/retries.