[zeromq-dev] Communication between C++ zmq client and Python zmq Server

Bernardo Augusto García Loaiza botibagl at gmail.com
Mon Feb 5 19:38:41 CET 2018


Thomas, I test any of two alternatives but my output when I build is :

/usr/include/c++/7/bits/stl_algo.h:806:27:   required from ‘_OIter
std::copy_n(_IIter, _Size, _OIter) [with _IIter = const char*; _Size = long
unsigned int; _OIter = void*]’
/home/bgarcial/workspace/sofa/src/applications/plugins/ZeroMQCommunication/ZMQServerComponent.cpp:92:65:
 required from here
/usr/include/c++/7/bits/stl_iterator_base_types.h:184:43: error: forming
reference to void
       typedef _Tp&                        reference;
                                           ^~~~~~~~~
applications/plugins/ZeroMQCommunication/CMakeFiles/
ZeroMQCommunication.dir/build.make:86: recipe for target
'applications/plugins/ZeroMQCommunication/CMakeFiles/
ZeroMQCommunication.dir/ZMQServerComponent.cpp.o' failed
make[2]: *** [applications/plugins/ZeroMQCommunication/CMakeFiles/
ZeroMQCommunication.dir/ZMQServerComponent.cpp.o] Error 1
CMakeFiles/Makefile2:10113: recipe for target 'applications/plugins/
ZeroMQCommunication/CMakeFiles/ZeroMQCommunication.dir/all' failed
make[1]: *** [applications/plugins/ZeroMQCommunication/CMakeFiles/ZeroMQCommunication.dir/all]
Error 2
Makefile:162: recipe for target 'all' failed
make: *** [all] Error 2


Is possible to this error make reference tto copy_n function return an int
value and I have inside void function ?
I've been searched about it, but the samples are in reference to another
cases more advances using templates and pointers between others ./..




Bernardo Augusto García Loaiza
Ingeniero de Sistemas
Estudiante de Maestría en Ingeniería Informática - Universidad EAFIT
http://about.me/bgarcial


On Wed, Jan 31, 2018 at 11:23 PM, Thomas Rodgers <rodgert at twrodgers.com>
wrote:

> Correction! Should read -
>
> std::copy_n(result.c_str(), result.size() + 1, request.data());
>
> OR
>
> std::copy_n(result.data(), result.size() + 1, request.data());
>
>
>
> On Wed, Jan 31, 2018 at 10:18 PM, Thomas Rodgers <rodgert at twrodgers.com>
> wrote:
>
>> Is this correct?
>>
>>
>> Yes
>>
>>
>>> 1. What advantages do I have when using something like protocol buffer
>>> to serialization data instead of
>>> send the data of a basic way such as I perform here turn the data to
>>> string and sending it?
>>>
>>
>> If you want to send complex data structures, portably between different
>> programming language environments and processor architectures.
>> This is not a goal of ZeroMQ and is explicitly left to other libraries
>> and tools.
>>
>> | 2.  Why use memcpy is bad or not suited?
>>
>> http://en.cppreference.com/w/cpp/algorithm/copy
>> http://en.cppreference.com/w/cpp/algorithm/copy_n
>>
>> are better alternatives in C++ and as, or more efficient than ::memcpy
>> (they in fact delegate, as inline code to ::memcpy if that is the fastest
>> way to perform the copy).
>>
>> your example would read -
>>
>> #include <algorithm>
>>
>> ...
>>
>> std::copy_n(request.data(), result.size(), result.c_str());
>>
>> OR
>>
>> std::copy_n(request.data(), result.size(), result.begin());
>>
>> On Wed, Jan 31, 2018 at 12:33 PM, Bernardo Augusto García Loaiza <
>> botibagl at gmail.com> wrote:
>>
>>> Hi Thomas, thanks for your appreciations
>>>
>>> In the memcpy function in the second parameter named const void *
>>> source ...
>>>
>>> void * memcpy ( void * destination, const void * source, size_t num );
>>>
>>>
>>> the  c_strt() function is suited place here because this  return a
>>> pointer to the variable value
>>>
>>> Is this correct?
>>>
>>> [image: Inline image 1]
>>>
>>> I am C++ and ZMQ newbie, although is a great idea measure dynamically
>>> the size of the request
>>> in the moment of send the data via zmq such as you tell me.
>>>
>>> According to this, the data is sent to my server and I can visualize
>>> your content of a suited way.
>>>
>>> I have two questions:
>>>
>>>
>>> 1. What advantages do I have when using something like protocol buffer
>>> to serialization data instead of
>>> send the data of a basic way such as I perform here turn the data to
>>> string and sending it?
>>>
>>> I've been check inside the zmq documentations about it
>>> <http://zguide.zeromq.org/page:all#Serializing-Your-Data>, but I don't
>>> have clear if serialization
>>> in first instance is necessary or which the advantages and against
>>>
>>>
>>> 2.  Why use memcpy is bad or not suited?
>>> I've been read about it, and I found ...
>>>
>>> memcpy copies a block of raw memory  from one location to another ...
>>> Several of the inconvenient are (basically it's a copy/paste from some
>>> links):
>>>
>>>    - Overlapping source and destination buffers: The behaviour of
>>>    memcpy is undefined if the source and destination buffers overlap
>>>
>>> How to could overlap the source and destination buffers  in one zmq
>>> operation? Is right think in this question?
>>>
>>>
>>>
>>>    - Maintaining alignment
>>>
>>> Data types such as integers and floating point numbers are often subject
>>> to an alignment constraint that limits where they can be placed in memory.
>>> For example, 4-byte integers must often be placed at an address that is a
>>> multiple of 4 bytes. Normally the compiler would ensure that alignment
>>> constraints are respected, but using memcpy it is possible to copy an
>>> object to a misaligned address
>>>
>>> In other site, I found this about of bandwidth demand copying things:
>>>
>>> There is nothing wrong with memcpy, except that it takes a long time.
>>> Excessive use of memory copying is sometimes a sign of poor program
>>> design.
>>> In a real-time system, it may be outright unacceptable. For example, if
>>> you
>>> copy the entire packet data at each layer transition in a protocol
>>> stack, you
>>> may find that your stack cannot handle as high a bandwidth as it
>>> otherweise
>>> could, thereby failing to meet requirements.
>>>
>>> In some lectures talk about of use memmove() instead of memcpy, in
>>> relation to buffer overlapping ...
>>>
>>> In the context  of performance and data transport via zmq, wha is the
>>> recommended option to
>>> use instead of memcpy
>>>
>>> Because zeromq in their website documentation samples, use memcpy
>>> <http://zguide.zeromq.org/cpp:hwserver> ?
>>> Is this a old version to work witn zmq to connect to socket and send
>>> data?
>>>
>>> Thanks for all your orientation about it.
>>> Best Regards
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Bernardo Augusto García Loaiza
>>> Ingeniero de Sistemas
>>> Estudiante de Maestría en Ingeniería Informática - Universidad EAFIT
>>> http://about.me/bgarcial
>>>
>>>
>>> On Tue, Jan 30, 2018 at 6:13 PM, Thomas Rodgers <rodgert at twrodgers.com>
>>> wrote:
>>>
>>>> You can’t memcpy a std::string, and in fact, you should t be using
>>>> memcpy in general in C++. I won’t go into the why of all of that here, but
>>>> start by changing -
>>>>
>>>> memcpy(request.data(), *&result*, 30);
>>>>
>>>> To
>>>>
>>>> memcpy(request.data(), *result.c_str()*, result.size() + 1);
>>>>
>>>>
>>>> On Tue, Jan 30, 2018 at 4:46 PM Bernardo Augusto García Loaiza <
>>>> botibagl at gmail.com> wrote:
>>>>
>>>>> Hi, I again.
>>>>>
>>>>> I've performed some small test in relation to the way on how to I
>>>>> sending the data member structure.
>>>>>
>>>>> I am turning the int data member structure to string before to be send
>>>>> it ..
>>>>> In the following code section  I am turn btnState in string data and
>>>>> assign it to string s variable and I contatenated it some additional string
>>>>> content and
>>>>> I sending this string concatenated result:
>>>>>
>>>>> void ZMQComponent::instrumentDataSend(instrumentData a){
>>>>>     /*  Initialize the data members structure instrumentData */
>>>>>     a.pos = sofa::defaulttype::Vec3d(1.0f, 1.0f, 1.0f);
>>>>>     a.quat = defaulttype::Quat(1.0f, 1.0f, 4.0f, 1.0f);
>>>>>     a.btnState = 5671;
>>>>>     a.openInst = 1.0f;
>>>>>     a.blnDataReady = false;
>>>>>
>>>>>
>>>>>
>>>>>    * string s, test, result, d;
>>>>>     s = to_string(a.btnState);
>>>>>     test = " is a number";
>>>>>     result = s + test;*
>>>>>
>>>>>
>>>>>
>>>>>     /*  We send  the btnState data  */
>>>>>
>>>>>
>>>>>     zmq::message_t request(30);
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> /*  We ask for the memory address to ge the btnState content and send it. */
>>>>>
>>>>>
>>>>>     memcpy(request.data(), *&result*, 30);
>>>>>     socket.send(request);}
>>>>>
>>>>>
>>>>> The output or the message which arrive to python zmq server is the
>>>>> content of
>>>>> result variable (btnState turn to string in s content variable +
>>>>> string test concatenated)
>>>>> and some symbols characters of the :
>>>>>
>>>>> (cnvss_test) ➜  Python git:(ZMQCommunication) ✗ python server.py
>>>>> ZMQ Server listening ...
>>>>>
>>>>> *Received message from Sofa: b'\xb0\x1d\x19\xf4\xfd\x7f\x00\x00\x0e\x00\x00\x00\x00\x00\x00\x0045 is a number'*
>>>>>
>>>>> If I assign a value less than 30 in the request, by example zmq::message_t
>>>>> request(10) the output in my server is:
>>>>>
>>>>> Received message
>>>>>
>>>>> ...
>
> [Message clipped]
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180205/393c8ba7/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 52201 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180205/393c8ba7/attachment.png>


More information about the zeromq-dev mailing list