Re: Talk to us first before you start reversing our protocol

[niahoo osef]

Well the message seems ok, and it works two with another server :

00:11:02.668 [debug] Outgoing IPC message
00 00 00 01  00 00 00 20  00 00 00 01  00 00 00 2B
00 00 00 06  00 00 00 00  00 00 00 02  00 00 00 02
00 00 00 00  00 00 00 18  00 00 00 03  00 00 00 0B
65 78 6D 6D  73 32 5F 63  6F 6E 6E

« If you indeed pass those two arguments, and they're rejected, then you
probably have to dig into the server and see how it's being received. »

I have no clue how to achieve that.

I tried the esperanza package client and it works.


Le 07/07/2017 à 23:23, Daniel Svensson a écrit :

On Fri, Jul 7, 2017 at 5:01 PM, niahoo osef  wrote:

Now that I want to test with actual music, I just installed xmms2 on my
xubuntu laptop (a mere apt install xmms2) but I have the following error :
Wrong number of arguments to hello.

How could I check the IPC protocol version that is installed on my laptop ?

The number of arguments have been the same since 2010. Your client
passes the IPC protocol version it supports to the server via the
HELLO command. The server may reject it.

This is what the HELLO message is supposed to look like:
https://github.com/xmms2/xmms2-devel/blob/master/src/ipc.xml#L150

If you indeed pass those two arguments, and they're rejected, then you
probably have to dig into the server and see how it's being received.




--
___
Xmms2-devel mailing list
Xmms2-devel@lists.xmms2.org
https://lists.xmms2.org/cgi-bin/mailman/listinfo/xmms2-devel

Re: Talk to us first before you start reversing our protocol

[Daniel Svensson]

On Fri, Jul 7, 2017 at 5:01 PM, niahoo osef  wrote:
> Now that I want to test with actual music, I just installed xmms2 on my
> xubuntu laptop (a mere apt install xmms2) but I have the following error :
> Wrong number of arguments to hello.
>
> How could I check the IPC protocol version that is installed on my laptop ?

The number of arguments have been the same since 2010. Your client
passes the IPC protocol version it supports to the server via the
HELLO command. The server may reject it.

This is what the HELLO message is supposed to look like:
https://github.com/xmms2/xmms2-devel/blob/master/src/ipc.xml#L150

If you indeed pass those two arguments, and they're rejected, then you
probably have to dig into the server and see how it's being received.

-- 
Daniel Svensson

--
___
Xmms2-devel mailing list
Xmms2-devel@lists.xmms2.org
https://lists.xmms2.org/cgi-bin/mailman/listinfo/xmms2-devel

Re: Talk to us first before you start reversing our protocol

[niahoo osef]

Thank you very much for your answers !

I have now a more clear vision of what I have to do. I managed to run 
the python code generator from xmms-alumni.


I learned that C enums increment values from the first name (which is 
defined to 32 in some enums in ipc.xml but not for the methods).


I'm not confident enough to rewrite genipc.py in Elixir, so I will use 
it with a custom code_generator.py that just outputs a new data 
structure with actual object_id and command_id numbers.


Then, I will write an Elixir module that reads the data structure and 
creates the appropriate modules with macros.


Thank you :)

Le 04/07/2017 à 11:21, Frank Terbeck a écrit :

Hi!

niahoo osef wrote:
[...]

With a friend, we are trying to implement the protocol of sending commands to
xmms2 via TCP in Elixir (or Erlang). We feel it's hard to find the appropriate
documentation but I eventually managed to gather some information on the wiki,
hence the title of this email.

When I was implementing a client library  in Scheme¹, I was faced with a
similar problem.  I have been  making a couple  of notes² along  the way
that may be helpful.


At the moment, we are able to send a hello command to the server. We figured
how to do this by looking at the code of a javascript client.

I would like to know where is the more fiable source that says that a "hello"
command is "32", that an error type is "1", integer is "2" and must be 64bits,
how to properly encode payload and what to expect in return, …

Most of  the server's API is  actually documented in a  machine readable
file³, which  you should use to  generate most of your  library. This is
true for constants (like what command id is correct for HELLO?) as well.

There are only a  couple of constants I couldn't find  in that spec, and
those are the identifiers for the protocol's types.


I don't mind reading any code but I'm far from good at C. I can't find the
python source code for a module named "xmmsapi" that xmmsclient depends on.

If Scheme makes you happier, feel free to  take a look at what I got⁴. I
think the first  ability you need is  to read data from  the server. For
that you  need to  be able to  parse a message's  header. Then  you need
serialisation and deserialisation  of the protocol's data  types to deal
with building and reading payload to and from the server. And after that
you can generate the actual API from ipc.xml.


Regards, Frank

¹ https://github.com/ft/xmms2-guile

² https://github.com/ft/xmms2-guile/blob/master/doc/xmms2-protocol.mdwn
   If you  clone the repository  and have pandoc installed,  this renders
   into  a PDF  as well  — I  don't know  if github's  Markdown rendering
   understands all the markup.

³ https://github.com/xmms2/xmms2-devel/blob/master/src/ipc.xml

⁴ https://github.com/ft/xmms2-guile/tree/master/tests




--
___
Xmms2-devel mailing list
Xmms2-devel@lists.xmms2.org
https://lists.xmms2.org/cgi-bin/mailman/listinfo/xmms2-devel

Re: Talk to us first before you start reversing our protocol

[Frank Terbeck]

Hi!

niahoo osef wrote:
[...]
> With a friend, we are trying to implement the protocol of sending commands to
> xmms2 via TCP in Elixir (or Erlang). We feel it's hard to find the appropriate
> documentation but I eventually managed to gather some information on the wiki,
> hence the title of this email.

When I was implementing a client library  in Scheme¹, I was faced with a
similar problem.  I have been  making a couple  of notes² along  the way
that may be helpful.

> At the moment, we are able to send a hello command to the server. We figured
> how to do this by looking at the code of a javascript client.
>
> I would like to know where is the more fiable source that says that a "hello"
> command is "32", that an error type is "1", integer is "2" and must be 64bits,
> how to properly encode payload and what to expect in return, …

Most of  the server's API is  actually documented in a  machine readable
file³, which  you should use to  generate most of your  library. This is
true for constants (like what command id is correct for HELLO?) as well.

There are only a  couple of constants I couldn't find  in that spec, and
those are the identifiers for the protocol's types.

> I don't mind reading any code but I'm far from good at C. I can't find the
> python source code for a module named "xmmsapi" that xmmsclient depends on.

If Scheme makes you happier, feel free to  take a look at what I got⁴. I
think the first  ability you need is  to read data from  the server. For
that you  need to  be able to  parse a message's  header. Then  you need
serialisation and deserialisation  of the protocol's data  types to deal
with building and reading payload to and from the server. And after that
you can generate the actual API from ipc.xml.


Regards, Frank

¹ https://github.com/ft/xmms2-guile

² https://github.com/ft/xmms2-guile/blob/master/doc/xmms2-protocol.mdwn
  If you  clone the repository  and have pandoc installed,  this renders
  into  a PDF  as well  — I  don't know  if github's  Markdown rendering
  understands all the markup.

³ https://github.com/xmms2/xmms2-devel/blob/master/src/ipc.xml

⁴ https://github.com/ft/xmms2-guile/tree/master/tests

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
  -- RFC 1925

--
___
Xmms2-devel mailing list
Xmms2-devel@lists.xmms2.org
https://lists.xmms2.org/cgi-bin/mailman/listinfo/xmms2-devel

Re: Talk to us first before you start reversing our protocol

[Daniel Svensson]

On Tue, Jul 4, 2017 at 3:45 AM, niahoo osef  wrote:
> Well,
>
> So here I am.
>
> With a friend, we are trying to implement the protocol of sending commands
> to xmms2 via TCP in Elixir (or Erlang). We feel it's hard to find the
> appropriate documentation but I eventually managed to gather some
> information on the wiki, hence the title of this email.

The client can be generated from this specification:
https://github.com/xmms2/xmms2-devel/blob/master/src/ipc.xml

As for the framing, theres unfortunately nothing more than source code:

> At the moment, we are able to send a hello command to the server. We figured
> how to do this by looking at the code of a javascript client.

Here's some WiP-elisp to cheer you up after all of that JS code! :)

http://b07d6c95b4f17404.paste.se/

...this is only the xmmsv_t parsing, not dealing with framing.

> I would like to know where is the more fiable source that says that a
> "hello" command is "32", that an error type is "1", integer is "2" and must
> be 64bits, how to properly encode payload and what to expect in return, …

Abraca actually does this when probing for servers on the local network:

https://github.com/Abraca/Abraca/blob/master/src/abraca-server-prober.vala

There you have a full hello and reply parsing. The reply parsing accepts both
pre and post service clients, pre service clients case can be ignored
if you're targetting xmms2-devel only.

> I don't mind reading any code but I'm far from good at C. I can't find the
> python source code for a module named "xmmsapi" that xmmsclient depends on.

The Python API will not help you as it simply wraps the C API. The
part of the C API you're after can be found here:

This is were all the dirty framing is built up:
https://github.com/xmms2/xmms2-devel/blob/master/src/lib/xmmsipc/msg.c

So message is basically:

32bit object id (see ipc.xml)
32bit command id (see ipc.xml)
32bit cookie for dealing with out-of-order and async results, you will
get this back with each reply
32bit length of payload
 payload, xmmsv_serialize(some_xmmsv_t). It's always a XMMSV_LIST_T

 And a reply is:
32bit object
32bit status
32bit cookie
32bit length

As you see, there's some confusion and legacy. Who needs object id
when you have cookie, and who need status when xmmsv_t can encode
errors. Oh well :)

It might also be helpful to read the testcases for the server, which
are fairly high level:

https://github.com/xmms2/xmms2-devel/tree/master/tests/server

-- 
Daniel Svensson

--
___
Xmms2-devel mailing list
Xmms2-devel@lists.xmms2.org
https://lists.xmms2.org/cgi-bin/mailman/listinfo/xmms2-devel