[Openchemistry-developers] Avogadro2 RPC?

[Patrick Avery]

I posted a bug report for it in Qt's system:
https://bugreports.qt.io/browse/QTBUG-61097

I guess we can see more information when they respond (and whether or not
it is some fault on my end)...

You can try downloading the .zip file in that bug report and compile the
test I made if you'd like. You just need to have two terminals open: one
running the server, and then another to run the client. If you try it, let
me know if you get the same issue (two packets being received instead of
one).

I also wrote a tutorial for using the avogadro2 rpc features in a program
(I have a C++ example and a Python example) in the avogadro-rpc-tutorial.md
file here: https://github.com/psavery/avogadro2-rpc-test

The examples are in that repository also.

Let me know if you think that is good for other people to use. I only
showed an example of receiving messages back in C++, but it should be
pretty similar in Python...

On Mon, May 29, 2017 at 12:08 PM, Marcus D. Hanwell <
marcus.hanwell at kitware.com> wrote:

> On Sat, May 27, 2017 at 8:24 PM, Patrick Avery <psavery at buffalo.edu>
> wrote:
> > I spent a good amount of time working through the Windows problem today,
> and
> > I think it might actually be a bug with Qt on Windows. I've also figured
> out
> > a work-around.
> >
> > Here is the problem. It has to do with operator<<(QDataStream &out, const
> > QByteArray &ba).
> >
> > https://code.woboq.org/qt5/qtbase/src/corelib/tools/
> qbytearray.cpp.html#_ZlsR11QDataStreamRK10QByteArray
> >
> > https://github.com/OpenChemistry/molequeue/blob/
> master/molequeue/servercore/localsocketconnection.cpp#L153
> >
> > It is supposed to work with QLocalSocket by creating a packet where the
> > first few bytes are a quint32 (which represents the size) and the rest of
> > the bytes are the actual data, and then send this packet. On Linux and
> Mac
> > this seems to work just fine. But on Windows, it creates two packets: the
> > first packet is the quint32 size and the second packet is the data. I
> don't
> > think it is supposed to create two packets, because the reading operator
> on
> > the other end of the communication (operator>>(QDataStream &in,
> QByteArray
> > &ba)) assumes it is one packet and fails to read it correctly.
>
> That is weird, we tested this out on Windows, but that was years ago,
> and I haven't done much testing recently. This would likely break
> MoleQueue there too.
> >
> > My current work-around is to avoid using operator<<(QDataStream &out,
> const
> > QByteArray &ba) to send that data via two packets by creating the single
> > packet myself and sending it manually. It is done like so:
> >
> >   // the Json file we are wanting to send is the QByteArray, jsonData
> >
> >   QByteArray byteArray;
> >   QDataStream tmpStream(&byteArray, QIODevice::WriteOnly);
> >   tmpStream << jsonData;
> >   socketDataStream.writeRawData(byteArray, byteArray.size());
> >
> > This still uses operator<<(QDataStream &out, const QByteArray &ba), but
> it
> > only uses it to write to byteArray (instead of writing it directly to the
> > socket). We then write to the socket manually by using writeRawData().
> >
> > This worked perfectly for me, and the messages are received just as they
> > should be. I'll document this in my how-to markdown file I write.
> >
> > The return messages in the RPC server have the same problem. Perhaps I
> > should implement my work-around in them so that Windows clients can
> receive
> > correct messages back (instead of the two-packet problem).
>
> Sound like a plan, is there an open bug report for Qt anywhere? This
> seems like something that would hit more people, and it would be great
> to resolve it upstream. The workaround mentioned seems reasonable, I
> would like to test it, and it sounds like this same approach should
> work on macOS and Linux too.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/openchemistry-developers/attachments/20170530/c4e5c16f/attachment.html>