Re: Talk to us first before you start reversing our protocol
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 osefwrote: 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
On Fri, Jul 7, 2017 at 5:01 PM, niahoo osefwrote: > 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
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
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
On Tue, Jul 4, 2017 at 3:45 AM, niahoo osefwrote: > 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