cohorte / cohorte-herald Goto Github PK

Allow peers to transfer files to each other, using transport-specific methods: HTTP GET, XMPP File Transfer (XEP-0096), ...

$ 2015-03-25 16:06:13,628:�[1;41mERROR�[0m:cohorte.composer.node.commander: Error calling composer on isolate serverrunner: No listener for 826F88A7433F4A24A6494501662AAD4B
Traceback (most recent call last):
File "/home/isandlatech/cohorte/dist/cohorte-1.0.0/repo/cohorte/composer/node/commander.py", line 228, in push_orders
composer.instantiate(components)
File "/home/isandlatech/cohorte/dist/cohorte-1.0.0/repo/herald/remote/herald_jabsorbrpc.py", line 234, in __call
reply_message = self.__send(self.__peer, self.__subject, request)
File "/home/isandlatech/cohorte/dist/cohorte-1.0.0/repo/herald/remote/herald_jabsorbrpc.py", line 269, in __call
return self._herald.send(peer, beans.Message(subject, content))
File "/home/isandlatech/cohorte/dist/cohorte-1.0.0/repo/herald/core.py", line 733, in send
if event.wait(timeout):
File "/home/isandlatech/cohorte/dist/cohorte-1.0.0/repo/pelix/utilities.py", line 525, in wait
raise self.__exception
herald.exceptions.NoListener: No listener for 826F88A7433F4A24A6494501662AAD4B

Requests is a good library, but its dependencies are problem when running on some interpreters or devices: six doesn't work "as is" with IronPython (it requires -X:Frames), requests requires the ssl module which isn't available on Arduino Yun, ...

It is necessary to replace requests by a homemade library:

• v1: make a Session class with a post method that mimics requests
• v2: implement a pool of connections to enhance performances

Instead or in addition of using protocol specific features to map the model of messages, it would be easier to support a body-only form.
Metadata and data would be together in the content part of the protocol used for transport.

This would simplify the writing of transport provider, or even to send messages using low level and non-Herald tools (echo + curl for HTTP transport, XMPP message from OpenHab, ...)

If the pyASN.1 library is installed, SleekXMPP will try to verify the certificate given by the server when using an SSL or a StartTLS connection.

It uses an _expected_server_name variable, which contains the server part of the JID given to ClientXMPP (set in BaseXMPP); to compare with various fields from the certificate.

In an anonymous login, no JID is given, therefore the ``_expected_server_name` variable is empty and doesn't match any certificate.

A solution is to set the _expected_server_name manually, before the XMPP connection, using the host name given to connect the server (if it is not an IP address).

Line: 162
https://github.com/isandlaTech/cohorte-herald/blob/master/python/herald/transports/xmpp/transport.py#L162

Fix by something like that one:

        # Connect to the server
        from time import sleep
        tries_delay = 5
        max_tries = 3
        tries = range(max_tries)
        connected = False
        for tries_remaining in tries:
            if self._bot.connect(self._host, self._port):
                connected = True
                break
            else:
                sleep(tries_delay)
        if connected == False:
        # if not self._bot.connect(self._host, self._port):
            _logger.error("Can't connect to the XMPP server at %s port %s",
                          self._host, self._port)

We should have only one file to modify when the version of the whole module is to be changed (not checking all files of all sub-modules to change them).

Integrate the implementation of Cohorte Herald Routing by @librallu (librallu/cohorte-herald) in Herald master branch.

• Use HTTPS instead of HTTP
• Avoid trusting all certificates in XMPP

Remove the dev branch from the git repository, as the development is now made directly on the master branch.

An application ID should be associated to each peer, so that two peers of different applications ignore each other.
This allows to reuse the same multicast port or the same XMPP rooms for different applications.

Meta-data should be no more transport specific concern. It should be sent encapsulated on the Message.

A peer can't have multiple accesses for the same transport, e.g. a peer using the XMPP transport can only use one JID, therefore only one XMPP server network.
This issue can be treated at transport implementation level, using a list of JIDs instead of a JID string as access. It should be fixed before implementing the Herald Routing messages.

• Provide a service (to generate access keys)
• Start a Pelix framework and wait for the order to stop

The Java equivalent of the Python XMPP transport must be implemented to ensure full compatibility with the Python implementation.

Often requested...

Cohorte-Herald Projects actually are maven first.
We should migrate all the Java projects to by Eclipse Plugins.
We use tycho+maven to build the projects on Jenkins (or local dev machines).

Happens on server side when calling a dummy method using XML-RPC, with both HTTP and XMPP transports.

Sample method:

class Test:
    def dummy(self):
        return

ERROR:HeraldNotify:Error executing herald_message:
Traceback (most recent call last):
  File "C:\Python34\lib\site-packages\ipopo-0.6.2-py3.4.egg\pelix\threadpool.py", line 397, in __run
    future.execute(method, args, kwargs)
  File "C:\Python34\lib\site-packages\ipopo-0.6.2-py3.4.egg\pelix\threadpool.py", line 119, in execute
    result = method(*args, **kwargs)
  File "C:\Python34\lib\site-packages\cohorte_herald-0.0.4-py3.4.egg\herald\remote\herald_xmlrpc.py", line 205, in herald_message
    herald_svc.reply(message, result, SUBJECT_REPLY)
  File "C:\Python34\lib\site-packages\cohorte_herald-0.0.4-py3.4.egg\herald\core.py", line 976, in reply
    self._fire_reply(beans.Message(subject, content), message)
  File "C:\Python34\lib\site-packages\cohorte_herald-0.0.4-py3.4.egg\herald\core.py", line 632, in _fire_reply
    transport.fire(peer, message, reply_to.extra)
  File "C:\Python34\lib\site-packages\cohorte_herald-0.0.4-py3.4.egg\herald\transports\xmpp\transport.py", line 761, in fire
    self.__send_message("chat", jid, message, parent_uid, target_peer=peer)
  File "C:\Python34\lib\site-packages\cohorte_herald-0.0.4-py3.4.egg\herald\transports\xmpp\transport.py", line 714, in __send_message
    content = utils.to_json(message)
  File "C:\Python34\lib\site-packages\cohorte_herald-0.0.4-py3.4.egg\herald\utils.py", line 93, in to_json
    return json.dumps(result, default=herald.utils.json_converter)
  File "C:\Python34\lib\json\__init__.py", line 237, in dumps
    **kw).encode(obj)
  File "C:\Python34\lib\json\encoder.py", line 192, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "C:\Python34\lib\json\encoder.py", line 250, in iterencode
    return _iterencode(o, 0)
  File "C:\Python34\lib\site-packages\cohorte_herald-0.0.4-py3.4.egg\herald\utils.py", line 59, in json_converter
    raise TypeError
TypeError

Currently, the XMPP transport requires a logged in bot to create required rooms and invite anonymous peers.
A better way to work would be to use a strong login policy for peers, even if their account would be generated by a bot

When exporting a service using Herald, it should be possible to select where the service discovery messages should be send.
Currently, they are sent to the "all" group, i.e. to all peers discovered by Herald.

We could add a herald.rpc.target.group service property, that would override this default target group.

• A group argument should be added for the utility method to send messages for the service discovery component:
  • Python: HeraldDiscovery.__send_message method
  • Java: HeraldDiscovery.sendMessage()
• The target group should be extracted from endpoint properties:
  • Python: endpoint_added/updated/removed()
  • Java: endpointsAdded(), endpointUpdated(), endpointRemoved()

Duplicate of: cohorte/cohorte-platforms#47