Would wxwidgets be performant enough to handle say thousands of sockets? From what I saw it only has events related to it but nothing as close to iocp from winsock or the io service in boost. Should I change my toolkit?
wxWidgets is a GUI framework. It happens to have a wrapper for native socket libraries as a convenience, but it is probably not a great idea to use this for something requiring thousands of sockets, where boost::asio would be more likely to be successful. Which GUI framework you use is a matter of taste and experience - use the one you like and are most familiar with. However, it will probably turn out better if the GUI and the socket server are designed to run as separate, co-operating processes - which further unlinks the choice of socket library and GUI framework.
Related
I need to make an architecture decision on a cross-platform app-suite. I basically want to try new way of decoupling modules and implement network I/O using ZeroMQ, knowing it's a message queue for in-process, inter-process and networking applications. But I'm not sure how it can fit in with my case.
I'd appreciate it if anyone could clarify a few things before I spend the next week reading their intriguing book: http://zguide.zeromq.org/page:all
I've checked these questions but didn't get my answers:
How to use zeroMQ in Desktop application
How to use ZeroMQ in an GTK/QT/Clutter application?
My requirements:
Desktop hosts on Windows and macOS, as separated console backend and GUI frontend; the backend must be written in C++;
Mobile guests on iOS and Android, backend written in C++;
Desktop talks with mobile using TCP;
Old Way
As for the desktop backend (the console app), a few years back, my first step would be writing a multithreaded architecture based on Observer/Command patterns:
Set the main thread for UI and spawn a few threads.
One "scheduler" thread for message handling: a queue to get notifications from other modules and another queue for commands. Each command type introduces its own dependencies. The scheduler pumps messages and issues commands accordingly.
Other "executor" threads for device monitoring, multiplex network I/O between one desktop and multiple mobile devices, all sending messages to scheduler to have real work scheduled.
I would then need to implement thread-safe message queues, and will inevitably have coupling between schedulers and a bunch of Command classes that are essentially just function wrappers of those executors' behaviors. With C++, this would be a lot of boilerplate code.
New Way to Validate
But it's 2019 so I expect less hand-written code and would try something new. With ZeroMQ, I'd love to see if my expectation holds. I'd love to ...
Remove the need of writing a scheduler and message/command queues from scrach, by just passing ZeroMQ requests between in-process modules across threads, because writing scheduling from scratch is tedious and unproductive.
Simplify network I/O between desktop and mobile devices. For this part I've tried ASIO and it wasn't significantly more convenient than raw socket and select, plus it's C++-only.
Decouple GUI and console app with ZeroMQ-based IPC, so that GUI can be rewritten using different technologies in various languages.
Perceive low-latency for both desktop and mobile users.
Is my expectation reasonable?
If new to ZeroMQ domains, feel free to review this and best enjoy a very first look at "ZeroMQ Principles in less than Five Seconds" before diving into further details
An above referred post has presented an assumption, that:
ZeroMQ is based on the assumption that there is an while (1) ... loop that it is inserted into
is completely wrong and misleading any Architecture planning / assessment efforts.
ZeroMQ is a feature-rich signaling/messaging metaplane, that is intended to provide a lot of services for the application-level code, that may enjoy a light-weight re-use of the smart, complex on low-level, efficient handling of signaling/messaging infrastructure, be it used for in-process, inter-process and inter-node multi-agent distributed fashion, using for that goal many already available transport-class protocols:
{ inproc:// | ipc:// | tipc:// | vmci:// | tcp:// | pgm:// | epgm:// | udp:// }
This said, let's follow your shopping-list :
My requirements:
c++ ZeroMQ: [PASSED] Desktop hosts on Windows and macOS, as separated console backend and GUI frontend; the backend must be written in C++;
c++ ZeroMQ: [PASSED] Mobile guests on iOS and Android, backend written in C++;
tcp ZeroMQ: [PASSED] Desktop talks with mobile using TCP;
I'd love to ...
Remove the need of writing a scheduler and message/command queues from scrach, by just passing ZeroMQ requests between in-process modules across threads, because writing scheduling from scratch is tedious and unproductive.
Simplify network I/O between desktop and mobile devices. For this part I've tried ASIO and it wasn't significantly more convenient than raw socket and select, plus it's C++-only.
Decouple GUI and console app with ZeroMQ-based IPC, so that GUI can be rewritten using different technologies in various languages.
Perceive low-latency for both desktop and mobile users.
Is my expectation reasonable?
Well :
there is obviously no need to write scheduler+Queues from scratch. Queue-management is built-in ZeroMQ and actually hidden inside the service-metaplane. Scheduling things among many-actors is on the other hand your design-decision and has nothing to do with ZeroMQ or other technology of choice. Given your system-design intentions, you decide the way ( "autogenerated magics" are still more a wishful thinking than any near-future system design reality )
[PASSED] QUEUES : built-in ZeroMQ
[NICE2HAVE] SCHEDULER : auto-generated for any generic distributed many-agent-wide ecosystem (yet, hard to expect in any near future)
network ( and any in principle ) I/O is simplified already in the ZeroMQ hierarchy of services
[PASSED] : SIMPLIFIED NETWORK I/O - ZeroMQ provides already all abstracted Transport-Class related services hidden to the transparent use of the signaling/messaging metaplane,so the application code enjoys to "just" { .send() | .poll() | .recv() }
[PASSED] : Decoupling GUI from any other part of the ParcPlace-Systems-pioneered-MVC-architecture. Using this since ZeroMQ v2.11 for a (far)remote keyboard over TCP/IP network and even possible to integrate into actor-based GUI, like Tkinter-GUI actors may well serve this distributed local-Visual/remote-distributed-Controller/remote-distributed-Model. If mobile-terminal O/S introduces more complex constraints on the local-Visual MVC-component, proper adaptations ought be validated with domain-experts on that particular O/S properties. ZeroMQ signaling/messaging metaplane has not been considered so far to contain any constraints per se.
[PASSED] : LATENCY - ZeroMQ was designed from the very start for delivering ultimately low-latency as a must. Given it can feed HFT-tranding ecosystems, the Desktop/Mobile systems are orders of magnitude less restrictive in the sense of E2E lump sum accumulation of all the visited transport + O/S-handling latencies.
I am designing a C++ app which consists of largely independent plugins or modules which produce from time to time results useful for other plugins. For example, analysis module comes across some useful piece of data and sends it to action modules. Each module will run in its own thread; this is so analysis modules can continue gathering data while action modules handle the data at the rate they can.
I am looking for a suitable message passing architecture/design pattern. This stackoverflow thread gives some suggestions, but I'm not sure a plain interface will work in multi-threaded environment.
I was thinking of having some sort of channel based architecture, where each module broadcasts something on the channel and whichever module is interested in it - listens to. If there are some ready made libraries under liberal licence - the better.
I've been using ACE (Adaptive Communication Environment) for thread management, TCP/UDP communications, mutex relationships and programming.
ACE is a highly portable collection of invocations of platform core patterns. Best of all, it's free, open source, and currently under active development.
http://www.cs.wustl.edu/~schmidt/ACE.html
For your application, I would recommend looking specifically at class "ACE_Task_Base" to provide multi-threading, and "ACE_Reactor" to register all the handlers for your asynchronous callback architecture.
You might be interested to take a look at ZeroMQ library that acts like a concurrency framework also. Using this library your components would communicate with each other by sending messages to named ZeroMQ sockets. There are many sockets types (TCP, IPC, inproc) and several patterns available for request-reply and publish-subscribe messaging.
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.
What is (are) modern frameworks for async IO, threading, etc. on C++?
I'am familiar with ACE but it was long ago, what is the the weapon of choice now?
What about BOOST libraries? It seems to be the most ubiquitous option right now.
It has threading and ASYNC-IO built in and many, many more libraries.
Poco C++ Framework and its network library:
http://pocoproject.org/documentation/index.html
Try Pulsar Server Framework. Main benefit is it is built over libuv network libary (used by node.js) that uses asynchronous I/O based on event loops. The frame
It’s perfectly scalable. You can just go adding servers as your user
base increases.
It is designed to work with server farm.
Highly configurable and easy to use
Currently it has been built for Windows x64 server.
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.