--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/f8fdc9b4-ef54-4e39-ad66-9f5b4d9eb042%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I haven't seen anything like that personally, but I also don't see all of the Channels stuff going on, so maybe there is one.It would be relatively easy to implement as a single class-based consumer that dispatches to RPC handlers based on method name, though, as it matches the consumer pattern very well.Andrew
On Thu, Jan 19, 2017 at 7:34 AM, Fabien Millerand <mill...@gmail.com> wrote:
Hi everyone,I am looking to implement a websocket server based on Django using JSON-RPC protocol.I have been looking around for a pre-made solution without success. I am also a newbie in Django so I am a little bit lost...Did anyone try to develop something like that?
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
Thanks a lot for your answer Andrew.
On a side note, would you be related to Mike Godwin? I just draw some moustaches on Trump's face 5 minutes before seeing your message... It is disturbing...
One thing channels do not do, however, is guarantee delivery. If you need certainty that tasks will complete, use a system designed for this with retries and persistence (e.g. Celery), or alternatively make a management command that checks for completion and re-submits a message to the channel if nothing is completed (rolling your own retry logic, essentially).
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/f52130e1-4ec4-48b7-b903-cadf22fb6d70%40googlegroups.com.
* A class than inherits from JsonWebsocketConsumer
* That class' receive() method decodes incoming messages, finds a handler function, and then calls that, taking the value it returns and sending it over the reply channel
* The user of it would then subclass again and implement JSON-RPC methods either as methods on the class itself, or using a dict in the class body to map names of methods to callables (your call on that one)
The non-delivery thing mentioned is the alternative you'd want, here, too - the alternative to non-guaranteed delivery (at most once) is guaranteed-and-possible-duplicate delivery (at least once), which for RPC systems generally isn't good - in RPC, it's easy to detect if a call didn't work as you won't get a response within a certain timeout.
Andrew
I am not sure to understand. In which case can there be messages/frames lost?! Where does that happen? Between the server interface and the Django layer? I would need to know more about that... Otherwise I might need to move with uWSGI or something.... JSON-RPC in itself doesn't implement a timeout, althought the javascript client better have one...
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/97e75375-6caf-4e8d-a781-be6da421840d%40googlegroups.com.
You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/b00Ie8wBPnc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFwN1uoPw%2BTjz3dmTvLeOck%3DHfRfRycA%3DHZ_GQa%2BbYBt7oXxwA%40mail.gmail.com.
Fair enough. I understand that in distributed system. But maybe you should add a note about that, as if the whole system is not distributed over network(s), it is highly unlikely to lose frames :D
On 25 Jan 2017, at 09:08, Andrew Godwin <and...@aeracode.org> wrote:
Yes, it's a bit alarmist if you don't come from the background of writing distributed systems. I just don't like to hide the truth one bit!All your software and hardware can fail in myriad ways; I have a talk I need to give about it at some point. Knowing how it fails is half the battle!Andrew
Ok, I start to understand now.To be frank the docs are a bit alarming :)
Le mercredi 25 janvier 2017 08:47:06 UTC+1, Andrew Godwin a écrit :I am not sure to understand. In which case can there be messages/frames lost?! Where does that happen? Between the server interface and the Django layer? I would need to know more about that... Otherwise I might need to move with uWSGI or something.... JSON-RPC in itself doesn't implement a timeout, althought the javascript client better have one...It simply means that it's possible that you might lose an incoming frame. This is also true of implementing it in uWSGI (the process handling the socket might get OOM killed, or the server might die, etc.)It's not a normal case, it's just that if something super bad happens, the resulting handling is to drop a message rather than play it twice. Most systems I know of that handle websockets do this.Andrew--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/97e75375-6caf-4e8d-a781-be6da421840d%40googlegroups.com.
Yes, it's a bit alarmist if you don't come from the background of writing distributed systems. I just don't like to hide the truth one bit!All your software and hardware can fail in myriad ways; I have a talk I need to give about it at some point. Knowing how it fails is half the battle!Andrew
On Wed, Jan 25, 2017 at 12:06 AM, Fabien Millerand <mill...@gmail.com> wrote:
Ok, I start to understand now.--To be frank the docs are a bit alarming :)
Le mercredi 25 janvier 2017 08:47:06 UTC+1, Andrew Godwin a écrit :I am not sure to understand. In which case can there be messages/frames lost?! Where does that happen? Between the server interface and the Django layer? I would need to know more about that... Otherwise I might need to move with uWSGI or something.... JSON-RPC in itself doesn't implement a timeout, althought the javascript client better have one...It simply means that it's possible that you might lose an incoming frame. This is also true of implementing it in uWSGI (the process handling the socket might get OOM killed, or the server might die, etc.)It's not a normal case, it's just that if something super bad happens, the resulting handling is to drop a message rather than play it twice. Most systems I know of that handle websockets do this.Andrew
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/49dbc038-46e5-402c-a810-900d47a561bf%40googlegroups.com.
You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/b00Ie8wBPnc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFwN1upCc96mWBP7ZCZm9y26ZJu7YRL7Q%3DvrxXOL43xx5Zc1gA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/49dbc038-46e5-402c-a810-900d47a561bf%40googlegroups.com.
--
You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/b00Ie8wBPnc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.