I'm not looking to use something big like QT or wxWidgets' APIs. I just want simple sockets that will work on Android, iOS, Windows, Mac, Linux.
I'm making an event driven card game so TCP would be best.
Essentially, I just want to connect and authenticate clients. After that I just need to be able to send them messages. I was going to use reliable UDP but TCP seems more appropriate.
If anyone also has basic tutorials for something like a tcp chat application I'd appreciate it.
Thanks
I just want to be able to use, send(), recv, etc without worrying about WINSOCK or POSIX,
Perhaps try BOOST Asio
http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio.html
Is that light weight enough?
I've made a really simple, lightweight wrapper around the BSD Sockets API. It does TCP/IP communication only, using a server and a client (a server can optionally accept multiple client connections).
You can find it here: (don't mind the Objective-C classes, use tcpconnect.h and tcpconnect.c only): http://github.com/H2CO3/TCPHelper
Perharps Boost.Asio (http://boost.org) or this one http://libunicomm.org based on Asio could be useful for you.
Related
Background
For my project, I'm attempting to control an AUV using an Arduino mega with an ethernet shield that receives instruction from a laptop (running Windows). The server side (laptop) will be written in C++.
Since there'll only be a one to one network using TCP/IP, I am trying to avoid the use of routers in order to simplify the hardware. I found out that you could do a direct connection between two devices (with auto-MDIX).
Therefore...
I have briefly looked into Boost:asio but I think it's probably an overkill (because I won't need to consider multiple clients etc) crossover for what I'm trying to achieve here. Am I right?
Any advice would be appreciated! Thanks.
TL;DR:
Looking for a C++ networking library (that works on Windows) that allows a clean, simple code to do a one-to-one TCP/IP connection.
The simplest way is to set-up your arduino as a web server. See this example sektch for the details.
On your Windows box use a web client library.
This way you can test the arduino even without your client software using your browser.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have one computer that is running a c++ program to control a robot and another computer that is running a computer vision system (also written in c++). I would like for these two programs to be able to talk to one another. The communication would not have to be complex, I would just need the robot computer to be able to tell the vision computer when a trial begins and ends (when to start and stop a data collection sequence). Do any of you have advice on how to approach this problem? Rs232 communication between the computers? Some kind of networking solution? smoke signals? Any suggestions would be welcome.
thank you in advance
(edit) In case you think the statement above is vague:
I need to pass a binary (go/don't go) signal from one computer to another. Unfortunately I can't be more specific about what this will look like because (obviously) I don't know what is available. Both computers are on a network, and both computers are running windows. The goal is to syncronize data collected by the computer vision system with actions performed by the robot. The communication does need to be fast enough that it will not slow down either the robot or the computer-vision program. a "good" solution would be 1) easy to implement 2) fast. I do not know much about networking and I am looking for a place to start looking.
thank you again for your assistance
You might use a simple UDP protocol - the advantage being that if you understand the concepts of simple packet protocols on RS232 you'll find it easy to transfer that knowledge to sending the packets via UDP.
If you want a reliable (as in, other parts of the system will worry about errors and retries) stream of bytes between the two PCs, then TCP/IP is not much more complicated to use than UDP.
Both UDP and TCP are accessed through 'sockets'. I'm afraid you'll find that from C++ there is rather a lot of tedious boilerplate to getting that working, but there are lots and lots of examples around.
If they are network-connected you could just use sockets.
The best option will be to use network communication. The easiest way to approach this should be to look at the networking examples in Qt.
You basically will create a client and a server application. You decide what the client does when it sees a certain message from the server. That's all. Qt should take care of the rest of the stuff.
Other answers suggests TCP/IP, UDP, RS232, ... All those things are just options when you use QtNetwork module. I assume that since you ask your question, you don't know about the difference between those. So the safest bet will be to use the highest level (free) library, hence the suggestion to look into Qt.
Another option is to use Boost.Asio. I tend to prefer Qt solution since their API is nicer.
That sounds like a fairly good use for the network socket. If both your machines are on Windows you can even use named pipes.
For Windows, you will need to open the COM n port as a file to communicate over a serial port[1]. I don't have access to my code now, I can look it up when I get home.
RS232 is easy and I like it. However, it it is slow. You need to consider that in your design.
[1] For C++.
Most modern computers have Ethernet capability, so get yourself a cheap hub or switch and look at networking APIs. There's usually some fairly easy socket stuff. One advantage of this is that, if you want to increase communication ability later, such as having your vision software provide instructions and guidance to your robot, you've got the basics set up.
Alternately, set up your vision program so you can start and stop it by hitting random keys. When you're going to use it, put the keyboard in front of the robot computer's CD drive, and eject at the start and end of the robot run.
This may be overkill in your situation, but if I were in your shoes I would probably implement it using the HTTP protocol. The vision computer would run a HTTP server and the robot computer would communicate the state changes using POST requests. The Poco C++ Net library provides you with the facilities required to do this.
I would use a TCP/IP socket for communications. TCP guarantees that the data will make it. So, all you need to do is parse the data.
RS232 is an easy option to program for, however modern PCs don't tend to have RS232 ports. You may need to get USB-RS232 adapters or install a PCI card.
The other problem with RS232 is that you have an additional wire to worry about which can be a nusiance. Also RS232 cables can be limited in length (5-15m) unless you invest in some clunky RS232 repeaters or bluetooth connectors, etc.
On top of all that you're also adding one more item to your project that can go wrong and cost you time in deploying and debugging.
IMO, an elegant engineering solution would be to utilise the hardware that you have and use TCP/IP sockets to communicate.
The web is awash with examples on passing messages between servers and clients:
If you're using Linux:
http://www.linuxhowtos.org/C_C++/socket.htm
Using Windows:
http://www.adp-gmbh.ch/win/misc/sockets.html
I also might look at something like 0MQ to make the connection more robust. It will transmit and reassemble messages regardless of the transport, and handle buffering in the case of temporary loss of connectivity.
But the bottom line is that I would use TCP/IP, but depending on the nature of the robot you may want a slightly more robust connection system than TCP sockets. UDP is nice because it's connectionless-- if the robot temporarily travels out of range/sight/etc you wont have to rebuild the socket and context.
I would like to create a chat application(desktop-app) in c++, so which protocol i would need to study and implement. UDP(?)
Please provide me some good thoughts and advices and links also.
UDP protocol is not the best choice for Internet chat program. UDP packets will be blocked by proxies. And UDP doesn't guarantee packets delivery. So probably TCP protocol will be a better choice.
Take a look on Boost.Asio Library. It already contains primitive implementation of chat program.
You don't give us much details here!
If your purpose is really to make a fully working and feature full chat application I suggest you look at XMPP which is an open instant-messenging protocol. Here is a list of some libraries implementing it.
If your purpose is to study network programming and you're more interested in UDP versus TCP for instance, then UDP is a bad choice for a chat application as it does not guarantee much about data integrity or ordering. Your messages might (and will!) be received in bad order or some might even be missing. TCP does that for kind of check for you.
In between (a very simple chat app) you can implement your very own protocol and use libraries others have suggested here like Boost.asio, ACE, POCO, or even wxWidgets and Qt, which will ease socket handling and also provide what you need to build a desktop app for the last 2.
Try using Boost.Asio. There are some examples of chat applications included in documentation.
You can use or look at an open-source networking library like ACE. A lot of goodies there.
You could use an existing library that handles instant messaging protocols, such as libpurple.
UDP is like a 'shoot and forget' kind of protocol. It's fast, but if you use it for communicating over the internet, there's no guarantee your messages will be recieved at all. Even if it's LAN, your packets can still be lost. It would be more convenient to use TCP which makes sure your packets arrive without errors and in the order you sent them.
I'm using C++/boost::asio under Win7.
I'm trying to "sniff" trafic over a given TCP/IP port. Hence, I'd like to listen on that port, receive messages, analyze them, but also immidately allow them to flow further, as if I never intercepted them. I want them to sink into the program that normally listens and connects on that port. Imagine a transparent proxy, but not for HTTP.
I'd rather find a code-based solution, but barring that, maybe you would suggest a tool?
what you are trying to do is basically a firewall program.
On windows there is several approach to do that, you can hook winsock. The better (or not hacky) is to use TDI filter (you take a look a this) or to make a NDIS filter.
Microsoft also introduced new API, WPF and LSP. I think you have better to use it because the TDI filter and NDIS wrapper involve driver programming which complicated and can be time consuming.
If this is for a product you are developing you may want to take a look at the WinPcap library http://www.winpcap.org/ which you can embed into your own program.
If you just need to analyze for yourself, use one of the tools that uses WinPcap, I have had great success with WireShark; but check out the WinPcap site for other tools
You cannot use boost::asio (or any other socket based library) for this as it consumes all the traffic.
Here's my question.
Right now I have a Linux server application (written using C++ - gcc) that communicates with a Windows C++ client application (Visual Studio 9, Qt 4.5.)
What is the very easiest way to add SSL support to both sides in order to secure the communication, without completely gutting the existing protocol?
It's a VOIP application that uses a combination of UDP and TCP to initially set up the connection and do port tunneling stuff, and then uses UDP for the streaming data.
I've had lots of problems in the past with creating the security certificates from scratch that were necessary to get this stuff working.
Existing working example code would be ideal.
Thank you!
SSL is very complex, so you're going to want to use a library.
There are several options, such as Keyczar, Botan, cryptlib, etc. Each and every one of those libraries (or the libraries suggested by others, such as Boost.Asio or OpenSSL) will have sample code for this.
Answering your second question (how to integrate a library into existing code without causing too much pain): it's going to depend on your current code. If you already have simple functions that call the Winsock or socket methods to send/receive ints, strings, etc. then you just need to rewrite the guts of those functions. And, of course, change the code that sets up the socket to begin with.
On the other hand, if you're calling the Winsock/socket functions directly then you'll probably want to write functions that have similar semantics but send the data encrypted, and replace your Winsock calls with those functions.
However, you may want to consider switching to something like Google Protocol Buffers or Apache Thrift (a.k.a. Facebook Thrift). Google's Protocol Buffers documentation says, "Prior to protocol buffers, there was a format for requests and responses that used hand marshalling/unmarshalling of requests and responses, and that supported a number of versions of the protocol. This resulted in some very ugly code. ..."
You're currently in the hand marshalling/unmarshalling phase. It can work, and in fact a project I work on does use this method. But it is a lot nicer to leave that to a library; especially a library that has already given some thought to updating the software in the future.
If you go this route you'll set up your network connections with an SSL library, and then you'll push your Thrift/Protocol Buffer data over those connections. That's it. It does involve extensive refactoring, but you'll end up with less code to maintain. When we introduced Protocol Buffers into the codebase of that project I mentioned, we were able to get rid of about 300 lines of marshalling/demarshalling code.
I recommend to use GnuTLS on both the client and the server side, only for the TCP connection. Forget about the UDP data for now. The GnuTLS documentation has example code for writing both clients and servers. Please understand that at least the server side (typically the TCP responder) needs to have a certificate; the client side can work with anonymous identification (although there is even an example without server certificate, using only DH key exchange - which would allow man-in-the-middle attacks).
In general, it is likely that you will have to understand the principles of SSL, no matter what library you use. Library alternatives are OpenSSL (both Unix and Windows), and SChannel (only Windows).
Have you tried the SSL support in Boost.Asio or ACE? Both use OpenSSL under-the-hood, and provide similar abstractions for TCP, UDP and SSL. Sample code is available in both the Boost.Asio and ACE distributions.
One thing you may need to keep in mind is that SSL is record-oriented instead of the stream-oriented (both TCP and UDP). This may affect how you multiplex events since you must, for example, read the full SSL record before you can call a read operation complete.
To help handle this with no changes to the application yo may want to look at the stunnel project (http://www.stunnel.org/). I don't think that it will handle the UDP for you though.
The yaSSL and CyaSSL embedded SSL/TLS libraries have worked well for me in the past. Being targeted at embedded systems, they are optimized for both speed and size. yaSSL is written in C++ and CyaSSL is written in C. In comparison, CyaSSL can be up to 20 times smaller than OpenSSL.
Both support the most current industry standards (up to TLS 1.2), offer some cool features such as stream ciphers, and are dual licensed under the GPLv2 and a commercial license (if you need commercial support).
They have an SSL tutorial which touches on adding CyaSSL into your pre-existing code as well: http://www.yassl.com/yaSSL/Docs-cyassl-manual-11-ssl-tutorial.html
Product Page: http://yassl.com/yaSSL/Products.html
Regards,
Chris