irmen / pyro4

Pyro 4.x - Python remote objects

Development Halted. Switch to Pyro5 instead.

PYRO4 - Python Remote Objects

Pyro enables you to build applications in which objects can talk to each other over the network, with minimal programming effort. You can just use normal Python method calls to call objects on other machines. Pyro is a pure Python library so it runs on many different platforms and Python versions.

This software is copyright (c) by Irmen de Jong ([email protected]).

This software is released under the MIT software license. This license, including disclaimer, is available in the 'LICENSE' file.

Python 3.10 is the End of the Line for Pyro4

Pyro4 is considered feature complete and new development is frozen. Only very important bug fixes (such as security issues) will still be made to Pyro4. New development, improvements and new features will only be available in its successor Pyro5: https://pyro5.readthedocs.io New code should strongly consider using Pyro5 unless a feature of Pyro4 is strictly required. Older code should consider migrating to Pyro5. It provides a (simple) backwards compatibility api layer to make the porting easier.

Pyro4 is tested to work with Python 3.10, but Python 3.11 and beyond are going to bring changes that will start breaking certain parts of Pyro4. This is not going to be fixed anymore in Pyro4. This basically means that Python 3.10 is the end of the line for Pyro4 and that running it on later Python versions will start raising certain problems. Pyro5 WILL get updates required to keep it running without issues on future Python versions.

Documentation

Documentation can be found online at: http://pyro4.readthedocs.io (or unformatted here in the repo at: docs/source/intro.rst)

Feature overview

Pyro is a library that enables you to build applications in which objects can talk to each other over the network, with minimal programming effort. You can just use normal Python method calls, with almost every possible parameter and return value type, and Pyro takes care of locating the right object on the right computer to execute the method. It is designed to be very easy to use, and to generally stay out of your way. But it also provides a set of powerful features that enables you to build distributed applications rapidly and effortlessly. Pyro is a pure Python library and runs on many different platforms and Python versions.

Here's a quick overview of Pyro's features:

• written in 100% Python so extremely portable, runs on Python 2.7, Python 3.5 and newer, IronPython, Pypy 2 and 3.
• works between different system architectures and operating systems.
• able to communicate between different Python versions transparently.
• defaults to a safe serializer (serpent https://pypi.python.org/pypi/serpent ) that supports many Python data types.
• supports different serializers (serpent, json, marshal, msgpack, pickle, cloudpickle, dill).
• can use IPv4, IPv6 and Unix domain sockets.
• optional secure connections via SSL/TLS (encryption, authentication and integrity), including certificate validation on both ends (2-way ssl).
• lightweight client library available for .NET and Java native code ('Pyrolite', provided separately).
• designed to be very easy to use and get out of your way as much as possible, but still provide a lot of flexibility when you do need it.
• name server that keeps track of your object's actual locations so you can move them around transparently.
• yellow-pages type lookups possible, based on metadata tags on registrations in the name server.
• support for automatic reconnection to servers in case of interruptions.
• automatic proxy-ing of Pyro objects which means you can return references to remote objects just as if it were normal objects.
• one-way invocations for enhanced performance.
• batched invocations for greatly enhanced performance of many calls on the same object.
• remote iterator on-demand item streaming avoids having to create large collections upfront and transfer them as a whole.
• you can define timeouts on network communications to prevent a call blocking forever if there's something wrong.
• asynchronous invocations if you want to get the results 'at some later moment in time'. Pyro will take care of gathering the result values in the background.
• remote exceptions will be raised in the caller, as if they were local. You can extract detailed remote traceback information.
• http gateway available for clients wanting to use http+json (such as browser scripts).
• stable network communication code that works reliably on many platforms.
• can hook onto existing sockets created for instance with socketpair() to communicate efficiently between threads or sub-processes.
• possibility to use Pyro's own event loop, or integrate it into your own (or third party) event loop.
• three different possible instance modes for your remote objects (singleton, one per session, one per call).
• many simple examples included to show various features and techniques.
• large amount of unit tests and high test coverage.
• reliable and established: built upon more than 15 years of existing Pyro history, with ongoing support and development.

pyro4's Issues

poll server doesn't keep track of self.clients

poll-server loop() doesn't keep track of self.clients.

This likely breaks the program when calling loop() multiple times in a row.
It should be possible to do this without losing the client set.

Simple example Pyro4

The most useful example I found in Pyro3 was the one called 'simple' which did basic arithmetic functions. I used this to understand Pyro and get it up and running on a couple of machines, in the end I based my project round it. It would be useful if this could be included as a Pyro4 example.

then() not called for exception

Hi,

using the greeting_maker exemple from the doc, the following snippet is never catching an exception:

    def error(result):
        print(result)

    p = Pyro4.async(Pyro4.Proxy("PYRONAME:example.greeting"))
    future = p.no_fortune('name').then(error)

and the exception (there is no attribute no_fortune) is only available when accessing future.value, which you don't know when to access without blocking since then() is not called.

Is that a expected behavior or bug ?

eventloop example is very slow with multiple calls (ubuntu)

Something weird is going on with the eventloop example; it can be very slow in handling multiple requests from the client.

Occurs on Ubuntu linux regardless of the socket server type and python version being used. Doesn't occur on OS X or Windows.

Problem was introduced somewhere after the 4.21 release (that one works fine)

serveSimple: reverse obj/name in dict

currently serveSimple accepts dict where the object is the key and its name is the value, it's more natural and more correct to use the name as key and the object as value.

Invalid pickle protocol between 3.3 and 3.4

From the "Tips & Tricks" page:
"When Pyro is configured to use pickle as its serialization format, it is required to have the same major Python versions on your clients and your servers. Otherwise the different parties cannot decipher each others serialized data. This means you cannot let Python 2.x talk to Python 3.x with Pyro. However it should be fine to have Python 2.6.2 talk to Python 2.7.3 for instance. Using one of the implementation independent protocols (serpent or json) will avoid this limitation."

However, when using pickle to connect Pyro (version 4.25 on both machines) between a machine running Python 3.3 and one running Python 3.4, I get 'unsupported pickle protocol: 4' errors.

It looks like this is due to the pickle.HIGHEST_PROTOCOL changing in Python 3.4 to be protocol 4, where in Python 3.3, it was protocol 3. I can make my issue go away by changing 'pickle.HIGHEST_PROTOCOL' to '3' on lines 375 and 378 of the Pyro4/util.py file. Maybe rather than hard coding the protocol, the Pyro4.config module could include something like a PICKLE_PROTOCOL setting?

add __getitem__ and friends to proxy

Actually, perhaps all methods mentioned in https://docs.python.org/2/reference/datamodel.html#emulating-container-types

tracking instances

I've been pouring over the api documentation, but I can't find an answer to my question. I haven't started coding anything yet, I'd like to make sure that I'm using Pyro as intended before I get too far in to the nuts and bolts.

I'm planning to write a daemon that handles client calls from the same machine, so there won't be any network complexity involved. The daemon will probably publish just one object, and the client's only purpose will be to create a new object in a new thread each time it's called, exiting without waiting for any response from the server (so the call is oneway); the init method in my class will take care of the rest so my client won't need to be overly complex. That said, processing on the object defined in init might take some time, and several of these objects will likely build up over the life of this program, so I'm wondering what tools are available in Pyro to manage the various instances. So basically I have some data that needs to be temporarily stored and processed, and I want to use Pyro as a centralized service for managing it all. Ideally I'd like to know how many instances of my class exist, and what options are available to control them on-the-fly, and how I might go about doing these things. If I could make the daemon maintain a list of active instances I could probably squeeze out all the functionality I need. Am I planning to use Pyro correctly, or should I look for an alternative?

use ex.__cause__ more when rethrowing exceptions

see PEP 3134. Use ex.cause to keep track of exceptions when rethrowing another. Will benefit Python 3.x

How to solve 'Don't know how to serialize class <type 'numpy.ndarray> ?

I ran a script that has a numpy array with Pyro4 and got that error, I googled and found that i needed to set export=PYRO_SERIALIZER = pickle

I ran it again but got different error : Pyro4.errors.NamingError : Failed to locate the namserver

that's weird as the server is running just fine

i changed export=PYRO_SERIALIZER = json , new errors : Pyro4.errors.ConnectionClosedError : receiving: not enough data

improve some unit tests that hang/crash in certain cases

python 3 on mac os crashes in test_socket (testMsgWaitallProblems, testMsgWaitallProblems2)
python 2 on ubuntu hangs in test_server (testPingMessage)

note that on windows (and using python 2.7 on mac) the unit test suite runs fine.

connection validator like Pyro3

abstract namespace sockets cause an error

If I try to use a pyro object with an abstract namespace socket on linux (i.e. one with a null byte as first byte of the socket address) I get the following error from pyro:

  File "/usr/lib64/python3.3/site-packages/Pyro4/core.py", line 581, in __init__
    self.transportServer.init(self, host, port, unixsocket)
  File "/usr/lib64/python3.3/site-packages/Pyro4/socketserver/threadpoolserver.py", line 84, in init
    if self._socketaddr[0].startswith("127."):
AttributeError: 'int' object has no attribute 'startswith'

It would be nice if pyro could support abstract namespace sockets as transports.

I'm using pyro-4.24 with python-3.3 on Gentoo Linux.

fix python 3.4 pickle issues

Pickle changed in python 3.4, see http://www.python.org/dev/peps/pep-3154/
This breaks Pyro. One of the things causing errors is the new getnewargs_ex method.

Also check if pyrolite's pickle implementations need to be updated

Is there something wrong ?

Here is the code in your document.

import Pyro4

class Thing(object):
def method(self, arg):
return arg*2

------ normal code ------

daemon = Pyro4.Daemon()
ns = Pyro4.locateNS()
uri = daemon.register(Thing())
ns.register("mythingy", uri)
daemon.requestLoop()

When I run it on my computer.
It always broken.
Pyro4.errors.NamingError: Failed to locate the nameserver.
Python version:
3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit (Intel)]
OS:
Windows 7 ultimate (64bits)

make the select/poll based server work in jython

Pyro's jython support currently only includes the threadpool server type. It will be nice if we also can get the select/poll based server working in jython.

fix the serpent error when serializing traceback in ironpython

see irmen/Serpent#2

require serpent >= 1.3 in next pyro release?

Unit tests are not compatible with Python 2.6

test_server.py and test_serialize.py use unittest.TestCase.skipTest() method which is new in Python 2.7.

server hooks for client connects and disconnects

sqlite3 ProgrammingError Exception rises ProtocolError

A sqlite3 ProgrammingError Exception while creating a new cursor will rise a ProtocolError from Pyro4 instead of showing the trace as explained in the tutorial.

Having:

sqlite3: 3.8.2-1ubuntu2
python2.7: 2.7.6-8
Pyro4: 4.23
serpent: 1.7

sys.excepthook = Pyro4.util.excepthook

The line that raises the ProgrammingError is

with closing(myConn.cursor()) as cur:

or

cur = myConn.cursor()

Having this function:

def func_test(self):
    query = "SELECT * FROM devices"

    print self.conn
    print "Before Cursor"

    cur = self.conn.cursor()

    print "Got a cursor"

    try:
        cur.execute(query)
    except sqlite3.Error:
        print "SQLITE Exception Raised"

    print "Query done"

Executed from the script will return:

<sqlite3.Connection object at 0x7f977ea53ce0>
Before Cursor
Got a cursor
Query done

Executed from the Pyro4 client script, will return:

<sqlite3.Connection object at 0x7f977ea53ce0>
Before Cursor

On my Pyro4 client, this traceback is shown:

Traceback (most recent call last):
  File "./myScript.py", line 40, in <module>
    myClass.resetCounter(device=param)
  File "/usr/lib/python2.7/dist-packages/Pyro4/core.py", line 160, in __call__
    return self.__send(self.__name, args, kwargs)
  File "/usr/lib/python2.7/dist-packages/Pyro4/core.py", line 314, in _pyroInvoke
    data = serializer.deserializeData(msg.data, compressed=msg.flags & Pyro4.message.FLAGS_COMPRESSED)
  File "/usr/lib/python2.7/dist-packages/Pyro4/util.py", line 154, in deserializeData
    return self.loads(data)
  File "/usr/lib/python2.7/dist-packages/Pyro4/util.py", line 404, in loads
    return self.recreate_classes(serpent.loads(data))
  File "/usr/lib/python2.7/dist-packages/Pyro4/util.py", line 315, in recreate_classes
    return self.dict_to_class(literal)
  File "/usr/lib/python2.7/dist-packages/Pyro4/util.py", line 294, in dict_to_class
    raise Pyro4.errors.ProtocolError("unsupported serialized class: "+classname)
ProtocolError: unsupported serialized class: ProgrammingError
sys.excepthook = Pyro4.util.excepthook

check all examples; do they work with serpent or do they require pickle

example "warehouse" doesn't work

Actually, for the phase3 of example "warehouse", when I run the code( I also tested the example code in the package ), it said
Pyro4.errors.NamingError: Failed to locate the nameserver

allow re-registering objects?

Re-registering an object that already is or was registered before is currently treated as an error (by design). I can look into this to see if this is a restriction that could be relaxed a bit.

Enhance FutureResult stacktrace

Long story short, I tried to send a cyclically referencing data object over Pyro without realizing it.

Had I sent it over a normal proxy, the full stack trace would have made it immediately obvious that the issue was in the serializer... and thus that the cause was the cyclic structure of the data object.

...
  File "build\bdist.win-amd64\egg\serpent.py", line 339, in ser_builtins_dict
  File "build\bdist.win-amd64\egg\serpent.py", line 240, in _serialize
  File "build\bdist.win-amd64\egg\serpent.py", line 310, in ser_builtins_list
  File "build\bdist.win-amd64\egg\serpent.py", line 240, in _serialize
  File "build\bdist.win-amd64\egg\serpent.py", line 437, in ser_default_class
  File "build\bdist.win-amd64\egg\serpent.py", line 240, in _serialize
  File "build\bdist.win-amd64\egg\serpent.py", line 339, in ser_builtins_dict
  File "build\bdist.win-amd64\egg\serpent.py", line 240, in _serialize
  File "build\bdist.win-amd64\egg\serpent.py", line 437, in ser_default_class
  File "build\bdist.win-amd64\egg\serpent.py", line 240, in _serialize
  File "build\bdist.win-amd64\egg\serpent.py", line 339, in ser_builtins_dict
  File "build\bdist.win-amd64\egg\serpent.py", line 228, in _serialize
RuntimeError: maximum recursion depth exceeded while calling a Python object

Instead, I was using the async system and the not-nearly-as-helpful trace left me searching the target code (which I had just overhauled) for a recursive call:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\Python27_64\lib\site-packages\pyro4-4.22-py2.7.egg\Pyro4\futures.py",
 line 93, in get_value
    self.__value.raiseIt()
  File "c:\Python27_64\lib\site-packages\pyro4-4.22-py2.7.egg\Pyro4\futures.py",
 line 140, in raiseIt
    raise self.exception
RuntimeError: maximum recursion depth exceeded while calling a Python object

I've traced the issue as far as the except block of _AsyncRemoteMethod.__asynccall where I can still reproduce the detailed log by cribbing code from elsewhere. I assume the non-exception _ExceptionWrapper destroys access to the appropriate trace, although I'm not fluent enough with Python errors to suggest a strait-forward solution.

If you setup a local nameserver, you can quickly reproduce my results with two consoles and the following code... run from trace_minimal_example import * on both then setup_server() on the server and run_client_test() on the client.

__author__ = 'Clayton Daley'

import sys, traceback, Pyro4
from time import sleep
from Pyro4 import util


def setup_server():
    class Pong(object):
        def ping(_):
            return "Pong"
    daemon = Pyro4.Daemon()
    pong = Pong()
    uri = daemon.register(pong)
    ns = Pyro4.locateNS()
    ns.register("ping", uri)
    daemon.requestLoop()

# Quickly construct an infinitely recursive data structure
message = []
message.append(message)

pong = Pyro4.Proxy("PYRONAME:ping")
ponga = Pyro4.async(pong)


def run_client_test():
    try:
        pong.ping(message)
    except:
        xt, xv = sys.exc_info()[0:2]
        print ("Exception occurred while submitting request: %s", xv)
        xv._pyroTraceback=util.formatTraceback(detailed=Pyro4.config.DETAILED_TRACEBACK)
        if sys.platform=="cli":
            util.fixIronPythonExceptionForPickle(xv, True)  # piggyback attributes
        print "".join(xv._pyroTraceback)

    print "^^ USEFUL TRACE ^^\n\n"
    sleep(10)

    a = ponga.ping(message)
    try:
        a.get_value()
    except Exception as e:
        traceback.print_exc()

    print "\n^^ FAR LESS USEFUL TRACE ^^\n\n"
    sleep(10)

    try:
       a.get_value()
    except:
        xt, xv = sys.exc_info()[0:2]
        print ("Exception occurred while submitting request: %s", xv)
        xv._pyroTraceback=util.formatTraceback(detailed=Pyro4.config.DETAILED_TRACEBACK)
        if sys.platform=="cli":
            util.fixIronPythonExceptionForPickle(xv, True)  # piggyback attributes
        print "".join(xv._pyroTraceback)

    print "^^ In the except block of _AsyncRemoteMethod.__asynccall, this code gives us the useful trace, but not here"
    sleep(10)

pyro fails to connect when using unixsockets and serpent serializer

There is a connection issue when I'm trying to use unixsockets, creating a nameserver, register some resources there and then trying to get uri's of these resources from another process using previously created nameserver. It returns correct uris but they are unicode strings (this seems to be due to serialization and deserialization) and according to this line:
https://github.com/irmen/Pyro4/blob/master/src/Pyro4/socketutil.py#L246
there is only type(connect) == str check to determine whether we use a unixsocket or a network socket and it fails because serpent returns unicode strings type(connect) = unicode. I think it would be better to check this another way: isinstance(connect, basestring) this should work fine in every case.

fix remote __dunder__ methods

Since last release every method starting with an underscore is treated as private and can't be exposed.

This is a problem for the dunder methods because these are treated differently by Python itself (not private even though they start with double underscores) and Pyro should treat them the same as regular remote methods.

Note that an exception will be made only for the double-underscore methods, any other method starting with an underscore will still be treated as private and inaccessible.

make sure that the essential dunder methods on the proxy such as init and hash still function correctly and don't start to call their remote counterpart!

override serializer on proxy

Currenty all proxies create a serializer based on the configuration setting. This setting is global so all proxies get the same serializer.

Add the possibility to override the serializer on a per-proxy basis. This makes it possible for instance to talk to the name server using serpent, and to talk to other objects using pickle

API documentation

Can I ask questions instead of reporting issues here?

Is it possible, when using Pyro4, the documentation of APIs can be generated automatically so that the client side can know what is provided on the server-side?

Or say, how can the client-side know what methods are provided on the server-side if the provider doesn't provide a API-documentation?

And we know some web-service( like using SOAP design) can generate API-doc automatically.

Thank you!

request: multiple processes providing the same object

I'm trying pyro for a project of mine and thought that the following may be a nice feature: Allow multiple processes to provide the same pyro object.

My use case is the following: I have a web application which has a pretty typical separation of python-frontend, python-backend, postgresql-database. The python code is stateless and so it would be nice to simply run several processes to get around the GIL. Thus the frontend would access a pyro-backend object and would transparently get one from an arbitrary process which provides them allowing for parallelization and load balancing without effort.

performance regression in connection creation (python 2.x)

There's a performance problem in connection creation: benchmark/connections.py is very slow when used with python 2.x (python 3 is ok strangely enough)

It appears it has been introduced in release 4.16, and seems related to the new thread pool. It doesn't occur when the multiplex server is used.

improve ns client scaling and/or documentation

improve scaling of Name Server: how many client connections does it accept?

documentation: add note about releasing the ns proxy to free resources for other clients. Improve http://pythonhosted.org/Pyro4/clientcode.html#index-8 a bit too.

autoproxy only works with pickle serializer

autoproxy only works with pickle, daemon.register only registers proxy serializer with pickle.
Make it available for other serializers as well (if possible - otherwise log a warning if it is enabled for an unsupported serializer?)

tests: Exception: Pyro4.errors.ProtocolError: invalid data or unsupported protocol version

I get the above exception during test suite and regardless that test suite continues as follows:

$ python run_suite.py 
............................................................................................................SS.S..S...............S.......................................................................................................Exception in thread Pyro-Worker-140056937633488 :
Traceback (most recent call last):
  File "/usr/lib64/python3.2/threading.py", line 740, in _bootstrap_inner
    self.run()
  File "../src/Pyro4/tpjobqueue.py", line 62, in run
    self.job()
  File "../src/Pyro4/socketserver/threadpoolserver.py", line 34, in __call__
    self.daemon.handleRequest(self.csock)
  File "../src/Pyro4/core.py", line 696, in handleRequest
    msg = Message.recv(conn, [Pyro4.message.MSG_INVOKE, Pyro4.message.MSG_PING])
  File "../src/Pyro4/message.py", line 156, in recv
    msg = cls.from_header(connection.recv(cls.header_size))
  File "../src/Pyro4/message.py", line 140, in from_header
    raise errors.ProtocolError("invalid data or unsupported protocol version")
Pyro4.errors.ProtocolError: invalid data or unsupported protocol version

..............E..E.....................

improve docs on nameserver discovery and registration

Improve docs on nameserver discovery: describe udp-broadcast etc better.

Improve docs on nameserver registration: server-side usage. Add paragraph to name server chapter. Refer to it from server code chapter.

use multiprocessing.pool as replacement for the custom threadpool implementation

Deprecate the custom threadpool implementation and replace it by using multiprocessing.pool (or rather, multiprocessing.dummy.pool).

Maybe multiprocessing.pool can also be used and this will introduce a new process based server.

Problem: jython and ironpython both lack the multiprocessing module. This means the custom threadpool server can not be removed completely.

Hang up if there is any exception occurred on the remote

>>> import Pyro4
>>> Pyro4.config.SERIALIZER = 'pickle'
>>> Pyro4.config.SERIALIZERS_ACCEPTED.add('pickle')
>>> p = Pyro4.Proxy("PYRONAME:test.controller")
>>> p.testcall('abc')

The parameter is invalid and will cause an exception on remote object.
But the local testcall() will always hang up until press the "Ctrl-C", it shows the traceback like this:

^CTraceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/testkit/env/local/lib/python2.7/site-packages/Pyro4/core.py", line 160, in __call__
    return self.__send(self.__name, args, kwargs)
  File "/home/testkit/env/local/lib/python2.7/site-packages/Pyro4/core.py", line 306, in _pyroInvoke
    msg = Message.recv(self._pyroConnection, [Pyro4.message.MSG_RESULT])
  File "/home/testkit/env/local/lib/python2.7/site-packages/Pyro4/message.py", line 156, in recv
    msg = cls.from_header(connection.recv(cls.header_size))
  File "/home/testkit/env/local/lib/python2.7/site-packages/Pyro4/socketutil.py", line 446, in recv
    return receiveData(self.sock, size)
  File "/home/testkit/env/local/lib/python2.7/site-packages/Pyro4/socketutil.py", line 152, in receiveData
    data=sock.recv(size, socket.MSG_WAITALL)
KeyboardInterrupt

Other information

Pyro version 4.22
Python 2.7
Platform: Ubuntu(Local) and Raspbian(Remote)

Can't import Pyro4 in Jython 2.7

Hi,

I don't know what I'm going wrong. I'm running Jython 2.7b1 however when I try to
import Pyro4
I will get:

ImportError: No module named Pyro4

However I installed the latest Pyro4 from git (using python setup.py install). I can import Pyro4 in Python 2.7.5 without any issues.

Can somebody please help me out?

Kind regards,
Melroy van den Berg

remove deprecations since 4.27

4.27 deprecated two things, remove these in upcoming release:

DOTTEDNAMES config item is deprecated and will be removed in the next version
setting proxy._pyroOneway manually is deprecated, remove support for that (+docs) (it will only be set by the metadata mechanism, just like _pyroMethods etc are)

decorators cont'd

Busy with getting @Pyro4.oneway working (with metadata exchange)
Add more: @expose (to mark exposed methods/attributes)
When used on class, initially mark everything unexposed?
When not used on class, everything should still be exposed (current behavior) - add config item to toggle this?

remote flame console won't close in IronPython

remote flame console won't close in IronPython

multiplexserver can be DOSsed when sending invalid protocol version messages

It seems that the multiplexserver can be DOSsed when sending invalid protocol version messages. It looks like parseMessageHeader will crash in such an event, which kills the server. Threadpool server is safe because it is only a worker thread that dies. (if it does die, it could still be improved... it's a waste of a thread. Alternatively, check that the threadpool deals with this correctly)

Allow SSL server sockets

As in some PaaS contexts is a bit harder to set a SSH tunnel over, what about allowing an SSL socket?

Just asking before starting to hack, but what about plugging ssl.wrap_socket over this sock via some argument switch?

Is this acceptable/desirable if I could provide a patch?

Pyro oneway execution order

In most cases, Pyro4 (intentionally or not) guarantees the execution order of proxied calls. For regular calls, the protocol blocks. For batch calls, a for loop in Daemon.handleRequest blocks. However, unbatched oneway calls are run in their own thread.

Assume you send two oneway calls back to back. I'm trying to figure out whether the execution order of these calls are guaranteed somehow... and, if not, clarify whether they're intended to be. I don't see anything obvious in the codebase providing this outcome, but figured it'd be safer and easier to just ask.

P.S. This seemed like something for the mailing list rather than Github, but you can no longer ask a question if you're not a subscriber. I don't need everything off a list just to get one answer so this seemed the next best option (but it'd be nice to have a better middle ground).

make it possible to register custom dict-to-class hooks

Pyro4 already provides register_class_to_dict to be able to serialize custom classes (to a dict).

It currently only knows how to deserialize a limited set of classes back from a dict. Add a register_dict_to_class method and a means to deserialize custom classes.

• add documentation about this feature.

enable multiple serializers at once in the server

It would be nice if it was possible to enable more than one active serializer in the server. This requires a change in the wire protocol: it needs to encode the serializer use.

improve test suite for ironpython and jython

The test suite could be improved to reduce the number of errors when running on ironpython and jython.

improve docs on various subjects

[done:] Improve docs on PYRONAME with hostname/port in uri, seems a hidden feature now

[done:] Describe serveSimple better. Also improve its apidocs.

[done:] Describe the clean way to shut down server. http://pythonhosted.org/Pyro4/servercode.html#cleaning-up ?

[done:] docs about command line tools.

review/add documentation on the new @decorators, METADATA features, direct attribute access.

update docs about repository move to github

improve documentation Table Of Contents

rst directive:

http://sphinx-doc.org/markup/misc.html#directive-index

Setting to disable use of MSG_WAITALL

I would like to request reintroducing the Pyro3 BROKEN_MSGWAITALL config item into Pyro4.

I just finished chasing down an infinite-hang issue on a large cluster machine that occurs when wire data is "big" due to Pyro's use of MSG_WAITALL with socket.recv(). I'm going to inform the cluster support team as this may be a kernel level issue that they need to be aware of. However, it would be a nice option to be able to tell Pyro4 to fall back on the old-style receive loop in socketutil.py, as this seems to resolve the hanging issue.