[Openchemistry-developers] Avogadro2 RPC?

[Patrick Avery]

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.

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).

On Thu, May 25, 2017 at 11:06 PM, Patrick Avery <psavery at buffalo.edu> wrote:

> Actually, for Windows, it looks like it might be working - partly at
> least. The same code I wrote for communicating through the RPC on Mac and
> Linux kind of works. As in, it seems that some messages get through, but
> not all. I might need to play around with it some and see if I can get the
> communication working consistently.
>
> I used the program "pipelist" to check if the avogadro server is being
> created, and it looks like it indeed is. I haven't tried compiling
> Avogadro2 on Windows myself yet, though.
>
> For Mac, however, my own compiled Avogadro2 generates the server
> correctly, but the mac binary on the website does not. I have been able to
> check it multiple ways - including seeing if my program can communicate
> with the server. When the server gets created, it is placed in $TMPDIR. So
> if I type "ls $TMPDIR/avogadro", I can check to see if it exists. When I am
> running the binary from the website, this is what happens:
>
> Mac-mini:~ patrick$ ls $TMPDIR/avogadro
>
> ls: /var/folders/90/6dyftwnx3jz5q4qwr79yb9f00000gp/T//avogadro: No such
> file or directory
>
>
> But when I am running the binary that I compiled:
>
> Mac-mini:prefix patrick$ ls $TMPDIR/avogadro
>
> */var/folders/90/6dyftwnx3jz5q4qwr79yb9f00000gp/T//avogadro*
>
> it's there. So I'm not sure why the binary on the website isn't producing
> it, then.
>
> Anyways, I'm going to keep looking at the Windows one for now. And I'll
> work on making some markdown documentation soon as well - since I know how
> to do it for sure on Linux at least.
>
> Thanks,
> Patrick
>
> On Thu, May 25, 2017 at 7:41 PM, Marcus D. Hanwell <
> marcus.hanwell at kitware.com> wrote:
>
>> On Thu, May 25, 2017 at 7:22 PM, Patrick Avery <psavery at buffalo.edu>
>> wrote:
>>
>>>
>>> I was able to meet (in person) and speak with Geoff yesterday. I think
>>> we are both on the same page that we'd like to see the RPC features in
>>> Avogadro2 be available in the binaries (and perhaps some documentation so
>>> that other programmers can more easily use it as well).
>>>
>>
>> Patrick, that sounds good. There was never an intentional removal of the
>> RPC procedure from the binaries, and I have been on this page for quite a
>> few years already ;-)
>>
>>>
>>> It is attractive because it would allow programmers working on any kind
>>> of molecular code to use Avogadro2 for the rendering of their
>>> molecules/crystals without having to link with Avogadro2 during
>>> compilation. It also allows for the rendering to be easily optional for
>>> users (if the user wants to render molecules with that program, they can
>>> download and start up Avogadro2; and if they don't want to render
>>> molecules, they don't have to do anything). I think this would certainly
>>> increase the number of people who use Avogadro2.
>>>
>>
>> Agreed, that is why I wanted to add some RPC capabilities, and think that
>> it is an important feature. This is why we worked on the RPC stuff, and I
>> have some ideas of doing this from a Python-based project.
>>
>>>
>>> I'm willing to help clean it up and write some documentation for it. So
>>> I was just wondering: what kinds of changes (if any) do you think need to
>>> be made to get the RPC features as a part of the released binaries? And
>>> where would the documentation go? I could write a "how to get your program
>>> to render molecules with Avogadro2 RPC".
>>>
>>> There isn't a great deal I am aware of, we could add an option to
>> disable the feature at runtime, but I think it is reasonable to enable it
>> by default. I will make sure the new binaries have the feature enabled (and
>> am not certain why this wasn't enabled last time). The local sockets mean
>> that only the local user can remote control Avogadro 2.
>>
>> In the first instance for documentation you could add a markdown file, or
>> put something  on the wiki. I have always hated the assumption that you
>> must link to C++ to use it, and would like to promote more local services
>> like this. Did you confirm this was not working on Windows and macOS?
>> Windows has always been a little finicky as it uses a different API than
>> macOS and Linux, but these are based on QLocalSocket.
>>
>> Hope that helps, and like I said more than happy to ensure the next
>> release features the RPC server, it reuses what was build for MoleQueue, so
>> I will see if I can find any issues in that.
>>
>> Marcus
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/openchemistry-developers/attachments/20170527/93f8a47e/attachment.html>