F
F
Flaker2014-03-06 19:30:10
C++ / C#
Flaker, 2014-03-06 19:30:10

(C++) Client-Server interaction. Multithreading. When? How?

As part of the study of client-server interaction, I am writing a 2D toy.

Lang: C++
IDE: VS10
Graphic: OpenGL
Interaction between client and server via sockets using UDP
Client part only under Win
I'm trying to make the server cross-platform .

Stumbled on the design of data transfer back and forth, and a few more things.
Namely:

1) Whether multithreading?
I looked at a lot of articles, but I still didn’t understand whether rendering , interaction and reading data are always separated in the clientthat came to the port, on different streams? Or maybe not streams, but somehow else? Tell me, please, how to do it right.

If it's not difficult, please throw off a link to digestible information about the cross-platform implementation of multithreading. But without Qt .

2) An infinite loop? Maybe callbacks?
As far as I understand, in order to constantly receive data, the one who came to the port in an endless loop chases recvfrom . Is it correct? Or is there a more attractive solution to this issue?

3) Cross-platform development in Visual Studio 10? Is it possible to?
I'm trying to make the server part cross-platform. Separating code with #if PLATFORM == PLATFORM_WINDOWS . How then can you compile the project underDebian or Ubuntu or any other systems?

3.5) Subtleties of cross-platform. Where?
Since I am not familiar with all the intricacies of cross-platform development, I can make mistakes and use features that may not be when compiled under *nix . How can I track the differences in the arguments of functions or the presence of the functions themselves under different axes ?

Answer the question

In order to leave comments, you need to log in

3 answer(s)
S
Sergey, 2014-03-06
@Flaker

1 . Drawing should definitely be moved to a separate thread from reading data
2 . As for the infinite loop, that's right. When you call recvfrom, your stream will be blocked until the data arrives, so you won't have anything to worry about using an infinite loop. That is why it is necessary to take out this whole thing in a separate process / thread.
3. Cross-platform development in vizhla? Alas, no, at least as far as I know. Read about cmake and just make (cmake is not good friends with vizhla, sometimes there are problems and after generating a project you have to spend more time setting it up, so it’s often easier to set it up once and carry project settings with you).
In general, it’s easier to wander around open source cross-platform projects and see how the whole thing is implemented there.
3.5 . Well, everything is simple here. on linux POSIX, on windows - WinApi (or WinRT if you have enough win8+ support). That is, let's say ... the server code working with sockets for these two platforms will differ by 90%, since everything is tied to the system api. That is, you need to make some kind of layer that encapsulates the network part, and already replace its implementation when assembling for a specific platform. Or take a ready-made solution for this layer. But when implementing business logic, the differences between platforms depend only on the logic itself.

L
Lolshto, 2014-03-06
@Lol4t0

Cross-platform is achieved by using cross-platform libraries. Use the features of the C++ Standard Library, learn boost.
In particular, for networking and task distribution boost asio.
Whether multithreading is needed or not is an ambiguous question. If the performance of one thread is enough, then it is better not to get into it. And in order to avoid delays, use asynchronous communication with the file system and the network, the concept of slot signals (boost asio, boost signals)

A
AxisPod, 2014-03-07
@AxisPod

In general, for the boost.asio network, it’s quite unambiguous (cross-platform, supports IOCP, epoll, kqueue, non-blocking sockets, asynchrony), for multithreading, either again boost or C ++ 11, in your case apparently boost (boost.thread, boost .atomic, boost.signals2), also take a look at tbb (non-blocking queues, algorithms and all that), easy, understandable, convenient.
Well, if you want on linux, you will have to support several compilers, as well as several standard libraries.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question