[zeromq-dev] Communication between C++ zmq client and Python zmq Server
Bernardo Augusto García Loaiza
botibagl at gmail.com
Fri Feb 9 20:02:39 CET 2018
Thanks Thomas, It's works
On Mon, Feb 5, 2018 at 11:41 PM Thomas Rodgers <rodgert at twrodgers.com>
wrote:
> The problem is spelled out in -
>
> [with _IIter = const char*; _Size = long unsigned int; _OIter = void*]
>
> ‘request.data()’ returns void*
> ‘result.c_str()’ returns const char*
>
> Try using ‘reinterpret_cast<char*>(request.data())’ instead of the bare
> ‘request.data()’.
>
>
>
> On Mon, Feb 5, 2018 at 12:56 PM Bernardo Augusto García Loaiza <
> botibagl at gmail.com> wrote:
>
>> 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
>>>>>>>
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180209/dbd7706f/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/20180209/dbd7706f/attachment.png>
More information about the zeromq-dev
mailing list