I have a pressing need for a tcp/ip-based (not udp-based) messaging system for something I'm putting together.
Something like rabbitmq or zeromq, maybe?
I'm not up on what are the current best-of-breed libraries, and it seems that none of them are currently bundled with pythonista 3, so anything I choose would have to be pure-python to be viable.
Any ideas or recommendations?
Anyone? Bueller?
Nobody using any tcp/ip messaging?
@shinyformica, I do not know if it is exactly what you are after, or ”best practice”, but I have used the free tier of the PubNub service for all my over-the-Internet messaging needs. It is fast enough for many in-house use cases as well, has a simple Pythonista-friendly API, and they offer message retention as well. Has worked well for me for years now.
Hadn't heard of it @mikael, but thanks for the info. Unfortunately, I can't use anything which requires an outside service...has to be all internal guaranteed-delivery messaging.
@shinyformica when you say messaging, are talking about "chat" app? Or literal low level messaging for some sort of client/server application?
I have used MQTT on embedded projects before. This is a subscribe/publish style messaging system, usually used for things like sensor data logging/distribution and control, but it is fairly low overhead and could be used as the transport for peer to peer comm. There are pure python implementations (I have used the micropython version, but there are at least a half a dozen different client implementations, a lot fewer python broker implementations that I could find)
Of course, there is also
https://github.com/mikaelho/multipeer
Which uses iOS frameworks for setting up the connection.
For very simple applications you might get by with the built in asynchat module. For example
https://pymotw.com/2/asynchat/
@JonB yeah, this is for low-level guaranteed delivery of messages containing arbitrary data for peer-to-peer communication.
Not looking for a server-client architecture, though that could work. More of a general peer-to-peer message queueing architecture. I did think of just implementing my own with asyncore/asynchat...but was hoping for something already built with best-practices and solid networking code, which is something I'm no expert in.
I'll look at MQTT, which I also had not heard of.
I believe mqtt would work -- I think it has ack/resend capability for example -- though may also be overkill. One peer would act as server (broker in mqtt parlance), and maybe would also have to run the client as well, though maybe not.
You could also use apples MFMessageComposeViewController. With that your program can automatically create a encoded message and put that onto apple messages to a receipient of your choice. The base64 encoded message databody should be prefixed with pythonista://nameofyourpyprogram?action=run&args=.... So that the Receiver just taps on the incoming message and jumps into your app. I wrote a mini tictoc app for fun which uses this method to asynchronously play with a friend. if you tell me that you want to go that direction, I could upload the example to github for you.
Personal, I use "IFTTT applets of webhooks service" to send a (Tappable) rich notification to my wife (not my friend 😀) via a Pythonista script. So, I don't need to pass through an "Apple messages composer". Of course, I need to know the IFTTT key of the recipient, instead of his/her phone number.
I wasn't clear enough in my original post...
What I'm looking for would not be used for inter-app communication, or any kind of communication on-device. It also can't rely on Apple-only, or external web-based services - it has to be able to work on completely private networks, perhaps without even any external internet access at all.
I'm looking for a good pure-python messaging library: both the message transport layer - i.e. the thing that packages up and delivers/receives messages over tcp/ip - and preferably the message protocol as well. Something to make it easy to send and receive arbitrary data between multiple iOS and desktop devices over a network.