How to use Web-Sockets in Python
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 132 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/44983 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EuroPython 201822 / 132
2
3
7
8
10
14
15
19
22
27
29
30
31
34
35
41
44
54
55
56
58
59
61
66
74
77
78
80
81
85
87
91
93
96
98
103
104
105
109
110
111
113
115
116
118
120
121
122
123
125
127
128
129
130
131
132
00:00
Physical lawServer (computing)Computer iconWorld Wide Web ConsortiumCartesian coordinate systemMedical imagingAbstractionContent (media)Web browserClient (computing)TelecommunicationWeb pageDependent and independent variablesServer (computing)Computer fontPhysical lawFront and back endsMultiplication signCycle (graph theory)Computer iconArithmetic progressionMultiplicationHidden Markov modelTask (computing)Communications protocolRight angleGoodness of fitAuthorizationComputer fileProgramming paradigm
03:19
Web browserServer (computing)World Wide Web ConsortiumNetwork socketComputer configurationDuplex (telecommunications)Message passingGame theoryVideo trackingSystem programmingPersonal digital assistantCache (computing)Error messageGroup actionCodeLine (geometry)DemosceneCross-site scriptingCollaborationismCursor (computers)Overhead (computing)Message passingReal numberServer (computing)Goodness of fitState of matterCodeRoboticsDuplex (telecommunications)Connected spaceObject (grammar)Level (video gaming)Uniform resource locatorFront and back endsError messageVideo gameMultiplicationSoftware frameworkLine (geometry)Client (computing)FeedbackArithmetic meanArithmetic progressionPhysical systemCASE <Informatik>CodeEmailHTTP cookieDependent and independent variablesMultiplication signGame theoryType theoryLoop (music)Noise (electronics)World Wide Web ConsortiumDebuggerSoftware developerGraphical user interfaceWeb browserDemo (music)2 (number)Communications protocolLibrary (computing)Network socketProxy serverQuicksortWordStandard deviationCausalityTelecommunicationFirewall (computing)Interface (computing)Real-time operating systemMoment (mathematics)ParsingImplementationNormal (geometry)Local ringComputer animation
10:48
Socket-SchnittstelleWeb pageDemo (music)DebuggerLibrary (computing)OvalGodZoom lensReal-time operating systemComputer-assisted translationPresentation of a groupVapor barrierCodeWordSource codeLine (geometry)LaptopRight angleWorld Wide Web ConsortiumNetwork socketInheritance (object-oriented programming)Computer animation
13:21
RobotClosed setLink (knot theory)Element (mathematics)Event horizonStructural loadElectronic mailing listClient (computing)Parameter (computer programming)Data structureSoftware frameworkNormal (geometry)Network socketCollaborationismDuplex (telecommunications)Inheritance (object-oriented programming)TelecommunicationCASE <Informatik>World Wide Web ConsortiumLine (geometry)Complex (psychology)Computer fileObject (grammar)MetadataBitMessage passingInstallation artOrder (biology)Open setOverhead (computing)Frame problemFront and back endsProxy serverFirewall (computing)Communications protocolComputer-assisted translationBootingVideoconferencingMultiplication signPhase transitionConnected spaceType theoryPhysical systemProjective planeServer (computing)RoboticsPresentation of a groupDemo (music)Library (computing)Moment (mathematics)Arithmetic meanString (computer science)Greatest elementLoop (music)Digital electronicsGame theoryBroadcasting (networking)Group actionFunctional (mathematics)InternetworkingSet (mathematics)CuboidContext awarenessExterior algebraSynchronizationDifferent (Kate Ryan album)WeightAxiom of choiceComputer animation
22:38
Client (computing)CodeSlide ruleDebuggerCartesian coordinate systemConnected spaceBitLine (geometry)Position operatorWeb browserDifferent (Kate Ryan album)TelecommunicationBuildingMereologyNetwork socketVirtual machineWorld Wide Web ConsortiumLibrary (computing)Semiconductor memorySingle-precision floating-point formatDirected graphThread (computing)MultiplicationDependent and independent variablesMessage passingMaxima and minimaComputer-assisted translationArithmetic meanWeb pageGastropod shellLoop (music)Sign (mathematics)Overhead (computing)Front and back endsCommunications protocolBefehlsprozessorOpen setLevel (video gaming)Product (business)Template (C++)CodeSoftwareInternetworkingSoftware testingRepresentational state transferCASE <Informatik>Control flowServer (computing)TrailWeightSimilarity (geometry)Sinc functionDefault (computer science)2 (number)Logic gateLink (knot theory)outputPoint (geometry)Perspective (visual)Information securityNormal (geometry)WebsiteObject (grammar)Cache (computing)Multiplication signParameter (computer programming)NumberImplementationStructural loadRight angleBand matrixDigital electronicsComputer animation
31:54
Computer animation
Transcript: English(auto-generated)
00:05
Thank you very much for coming. It's a pleasure to see all those new and familiar faces here in this room Have you enjoyed the conference so far? Yeah, I did too. Good. All right. I have a first question to you You've probably heard of a saying like if all you have is a hammer everything looks like a nail
00:24
You certainly did. Well, it's not just a saying It's actually something formulated as law of the instrument by the American philosopher Abraham Kaplan But not the Kaplan Moss the Django author has nothing to do no different thing. Yeah Well, anyway, what does it have to do with today's talk thing?
00:41
Is that I believe that this saying it perfectly illustrates the way we work with the web today and the way we are using HTTP We're a bit childish by using HTTP because it's our hammer whatever task we have HTTP do it do it, please But there is more than HTTP on the web So HTTP was not designed to do the tasks that we often force it to do
01:03
The protocols itself the HTTP is just centered around the request and response. That's it. There is no progress reporting There is no multiple Requests or responses for requests anything like that if you need something you can build an abstraction of top, of course But at the end even if you build like the pseudo async communication with HTTP
01:22
It still does not change the way the underlying HTTP protocol works It's still synchronous and it's still centered around the request and response cycle So again, the idea is that simple in the good old times there was just a request to the back end We fetched the page we displayed it. That's it easy Well, then the web evolved, of course, it became smarter so that we needed the application server
01:44
It also became a beautiful so we needed the CSS images fonts files And then it's the picture changed smallest like this. So we still have our browser the client It makes requests to the web server to get stuff more stuff now and even more stuff
02:00
But it still fits in the paradigm still fits into the way the HTTP is supposed to work just more requests But that's okay The first time I noticed I remember that something goes wrong here is when I had to deal with the icons Do you remember a good old times of the icon sprites? like this It was the obvious problem like hmm we have too many icons that means too many requests HTTP is not handling that
02:26
Well, what can we do? Oh, let's pack all of the icons into one image and just offset it To the left and to the right genius Well, this is something that I mean by the web abuse and using the HTTP not in the way It is designed to be used. It has nothing to do with web sockets, but the story is going
02:44
then Async requests. So the problem was fixed by introducing Ajax when we thought like, okay we need some periodical updates of our content without reloading the whole page and Then we got Ajax but at the end it's good However Ajax does not change anything for the back end Ajax is a pure client-side technology for the back end
03:06
It looks totally the same way and it's again the very same HTTP Moreover if you take a look on how exactly the paradigm how exactly Ajax update works Like we wanted to get something like a dialogue between the client and the server. What's the dialogue?
03:21
Well dialogue is like when two parties Exchange their opinions. They're equally involved. They are respecting each other This is a dialogue, but how our dialogue between the browser and the back-end look it's more like this Because at the end we are dictators. The client is a dictators. The servers are not allowed to speak only when we ask
03:43
so it is kind of a funny way of doing dialogue in my opinion and And so although Ajax solves this problem partially meaning that we can just periodically ask The back end about the updates and it's a pseudo dialogue. It's still ugly So yeah, as I already explained we have a couple of problems we have
04:05
First problem is that the dialogue is not really a dialogue It's a pseudo dialogue and the second is that you still need a lot of requests and the more frequent updates You want the more requests you do and this obviously does not scale well Moreover you are still using HTTP on the
04:22
on the background HTTP has quite a high noise to the signal ratio meaning that you send all of the headers all of the cookies Everything just to get a response from the back-end. Nothing you happened That's not cool. And then we come to the long polling. Well, this is already something this is already some progress
04:42
Let's say we open the connection. We keep the connection alive Connection is just idling idling idling and whenever something new happens on the back end. We push it through Well, that's great HTTP overhead is still in place. But at least it's not periodical as Ajax It's waiting for stuff idling and it's in my opinion. Well, it's of course good because
05:05
mmm, you get things asynchronously and it's even better because Long polling is kind of romantic because if you think of it, it's like looking in someone's eyes when no words are needed You just wait and wait and wait and then and then he or she replies something to you
05:25
The problem is I don't think that's my level of relationship is already there on the web. I don't want it enough, please Every time you use long polling a guy from Boston Dynamics kicks the robot Now Finally enough of this nonsense
05:41
There is just one way to do the real-time bidirectional communication between the client and the server and that is web sockets Nothing else forget socket IO forget this libraries that are built on top of usually long polling and in the worst case Ajax They are outdated. There is totally no reason not to use web sockets these days as the developers we can finally benefit from from web sockets because
06:04
We have no longer a problem of the HTTP overhead we have no longer a problem of the real full duplex connections meaning both parties can start talking to each other as a normal dialogue and Finally, the interface is really easy from the client as well as from the server
06:21
I'll show you in a moment a couple of code pieces and as well as a demo But first just web sockets in a glance. So another cool advantage is that the web sockets They are not HTTP, but they are compatible with HTTP meaning that they run on ports Used by HTTP 80 and 443. So all of the firewalls will work
06:44
All of the proxies will probably just let it through So basically you do not need any new setup in your infrastructure You can just use nginx or whatever reverse proxy you use. It should just work then How exactly we we jump from the HTTP to web sockets protocol
07:02
We start normally as we always did with HTTP We do the the handshake we establish a connection and then our client Says to the server that hey I want to upgrade to the web sockets protocol and if the server supports it it says yeah do it Then they establish this connection the full duplex TCP connection
07:21
They do not communicate over that connection with HTTP now it's pure web socket connection meaning that HTTP headers do not go through it and This is cool because we're not sending HTTP overhead anymore to the client every time. All right Let's go for the use cases So obviously it's stupid to say just use web sockets for everything because there are good sides and bad sides
07:46
So the good cases for web sockets are any cases when you need to implement kind of a multiplayer behavior It's obviously games. It's also tracking system when you have multiple objects Let's say moving on the map and you need to update their locations in the real time
08:00
This is like typical scenario for web sockets Also the collaborative editing Google Docs when you have again multiple cursors writing text at the same time. That's exactly the case However, as I said, there are also bad cases to implement web sockets First of all, because you are with losing a shitty with losing the HTTP overhead
08:20
You're also losing the benefits of HTTP and that is caching that are the standard HTTP responses like 400s for 400 500 and so on most of our JavaScript Clients these days they automatically react to the problems to the error cause of HTTP Like if you return 500 so the your web framework will know that it's a server problem 400
08:44
It's a client problem. Well on web sockets. We don't have an overhead meaning we don't have status codes Well, all that you get is just a message a pure message and then it's up to you to handle it So if you want to say there was an error You cannot send the status code because there are no status codes You have to somehow encode it yourself and then on the client parse it yourself and see oh, this was an error
09:03
So remember this Then in HTTP, we know that get requests are idempotent meaning that you can repeat it as much as you want in web sockets You cannot say it again. It's just sending a message. There are no gets and posts in web sockets It's just sending a message so it's up to you to decide if you want to build it in idempotent fashion on the backend or not and the
09:24
Client also has nothing to do with it Now, let's see a little example as I mentioned already web sockets are really really easy so to prove it here is the vanilla JS example of What do you need to do to establish the connection with the backends?
09:42
Can you see it? You can oh, that's that's great. That's already something I Don't have the mouse here. But alright, I'll just comment it like this So as you see we're just not using any sort of libraries, it's a pure JavaScript You open the debugger in Chrome and that's what you need to type
10:00
So you are creating first the web socket connection to that hosts in this case local host and then you define three callbacks What to do on open when the connection is established what to do when you get the message in this case I'm just appending it to the document body and what to do on error. Obviously nothing like who cares of that these are Ten lines that you need to write to use web sockets
10:23
So it's really really easy now. It would be of course boring if I wouldn't come up with a demo I thought like I want to get some feedback about this talk and the best feedback for a speaker is Obviously throwing tomatoes on him so I Really like this shirt. So please don't do it right now, but you can do it on the web
10:43
So if you just go to oh, this is the wrong URL You go to I'll just do it with you Go to demo dot customers dot me
11:00
Slash euro Python you don't have to do it. But if you have a laptop anyway, you can just do it then you learn how to How to use web sockets. I here I have a little code snippet. I'll just zoom zoom in for you
11:22
I didn't make it much better. Anyway, you'll get the idea. So if you copy this Into the debugger
11:42
Yeah, I saw that someone already did it you are throwing tomatoes on the speaker Well, you might think that this guy is actually not so bad. Like I do not want to throw tomato on him I better throw a candy. You can do that too then instead of tomato over there
12:00
You're right candy. Oh somebody throw an egg on me. Oh, that's bad. All right. Well anyway, have fun Have fun with it. What this demo shows is that when all of you are throwing tomatoes on me I like tomatoes that's fine. When when you're doing it one person throws it and everyone sees it everywhere because on the background what you do is you send oh my god
12:28
Could you please send some candies to or cats you can send cats by the way? My god. Yeah, so you see it's updated in the real time One person sends everyone receives it and if you like reload, oh, this is sweet if you reload the page
12:44
Then you get it all at once It's just the web socket is pushing through everything that it received by now and this is just that Three lines four lines over there and you can watch you can see the source codes. There are no libraries involved at all It's just one HTML page with JavaScript in lined
13:01
Super easy super cool. I want to say to you that there is no barrier in not using web sockets these days Now back to the presentation. You can have fun meanwhile. Let's let's see at the end Let's see at the end what's there I'm really interested now, okay
13:24
Now we still have time to see how much time do we have 15 great. So now we obviously want to see it's a Python conference. How can you use it from the backend side? So we have a several frameworks that can do it and the easiest one is tornado. Well in my opinion
13:44
Tornado is kind of a flask but the async way You all know that flask is super minimalistic, but tornado is also minimalistic You can have just one PI file and this is actually all that you need this 26 line 26 lines to run the web server with web sockets and you have here already the handler implemented
14:04
This is literally all you need to do pip install tornado that you have it running now Let's just have a few if you come in some what exactly does it do? It's very very much similar to what we do on the client side. We define three callbacks on open on message and on close
14:21
What what should we do? And when you receive a message obviously or the one message callback is triggered And in this example, I'm just sending it back. I do sell that right message. Hello, and this just sends back Hello, and whatever you received at the beginning That easy, of course, it's not so easy if we want to throw tomatoes on the speaker
14:40
gets a bit more difficult because you want some place to store all of the thrown objects and Then you want to send it not just to one client You want to send it to all clients meaning the broadcasting but for this you can just use plain Python tools Just append everything to the list and then when the new client connect iterate on that list and send it back. So
15:02
There is no magic it's just normal Python data structures in this case I implemented it super simple on purpose like you do not need any kind of readme file for this super easy But if you want more complex setup because it's still minimalistic now, you can take a look on Django Django channels
15:20
It's very different because Django in the first place is a synchronous web framework So you cannot run web sockets on Django out of the box because it just does not work by design What they did it was a good idea They created a synchronous server next to the synchronous server So actually when you send the web socket data in Django, you're not sending it through the main web server
15:42
you're sending it on kind of alternative one, which is a synchronous which supports the thing and then they integrate so Please understand that Django channels has Little to do with Django. They tried to write it in the similar way and they succeeded But it's still two different libraries working in totally different ways
16:02
They are somehow integrated and the tool set is really cool and really huge It's nothing comparing to tornado because it has all of the broadcasting features the sessions the users Tornado doesn't have it. You have to implement it yourself. So like in Django channels, it's relatively easy to say To map the user to the web socket connection
16:20
If you want if you want to split your users by group Like only this group will receive this message and Django channels. It's easy internet You have to do it yourself, even though it's also easy, but you have to do it Okay, now let's go to the next one the bonus one the web sockets package called web sockets This is how it looks. This is really the most minimalistic thing I have found so that you have just one
16:46
function one handler that Is handling your web socket connections and here you can use the asyncio library with async await syntax if you like So I think it's quite self-explanatory. I tried to build up this example very minimalistic again
17:01
you do the await web socket receive meaning that you Idle in that moment until the data arrives when it arrives It's written to the name variable Then you formulate the string that you want to send back and then you again do the await web socket dot send Sending it asynchronously and that's it. And that three lines on the bottom are just running the asyncio IO loop quite standard stuff
17:25
I would say and you can integrate those because tornado runs on I think not out of the box, but it supports asyncio IO loop so you can run both I don't know. Why would you need this but people ask these questions if I can integrate this you can All right, so this looks already like some dialogue to me if you use web sockets I
17:45
Noticed your reaction to the guy kicking the robots from Boston Dynamics I see that you're also concerned about this topic. So I think at the end of the presentation It's important to show you that there is a petition The robot abuse and the best thing are the comments there. So feel free to sign it
18:06
I think it's outdated, but it's hilarious. I had to add it there now the commercial time Sales time I run a Python agency if you have projects or you're interested in doing a project with me, please contact me Let's see how many tomatoes are on me by now. Lots of cats. Well, this is nice. It's like a paradise
18:29
The funny thing is that I was really in a rush for this demo so I have no way to flush it now I need to redeploy the whole thing But I think I will not because it's really cute, isn't it
18:42
Okay Yeah, then last thing The credits there are really cool Articles online about web sockets and about using them with Python also the videos and that's it. Thank you very much Okay, anyone a question, please stand up and come here. You said that
19:17
It's over the HTTP the web socket
19:21
You start So can we have all the it's a get I think it's a get request at first and can we have all the parameters there like a Get a get parameter get parameters just to know what to send We have to do with with this web circuit. Mm-hmm. Thanks for the question
19:44
So, yes, you start with HTTP because you never know if the back-end supports The web socket you start with you are connecting as if you are connecting an HTTP But you only do it not to send the data You only do it to ask if we can upgrade to the web socket connection
20:03
And if you can there are no get requests. There are no parameters nothing so if if the server and the client both Support web sockets protocol as soon as the connection will be established you totally forget about HTTP So no You cannot get parameters and you do not have statuses and you do not have request types like get post boot
20:24
it doesn't exist HTTP is really used just as a transport at the first phase to establish the connection and that's it and it is done that way in order to be Compatible with firewalls reverse proxies and so on. So the protocols are very different they have
20:40
Not so much similar because the web socket was developed in order to maximally decrease The overheads of sending messages back and forth basically in web socket everything you sent almost everything is a message there are a few frames at the beginning of the data frame indicating the order so that the backends can then
21:01
Combine this web socket message pieces into one big message and that's it. That's all the metadata that is sent. So no parameters Thanks more questions
21:22
Yeah, so how practical our web sockets in Python Of course Well, first of all most of the things that as I mentioned the in the use cases of collaborative editing
21:40
Multiplayer games and tracking systems are already on web sockets like Google Docs. So it's quite a big project I would say it's not in Python unfortunately, but It's basically the only way that you can do the reliable full duplex communication these days between the client and the server So it's not like you have much of a choice. You can use Ajax. Yes, but if you have imagined like this room
22:05
right now Sending these cats with Ajax, I mean my poor server would just die From that and since you use in context of Python I can mention again that it's a spatial well playing in Python because you have a sync await syntax
22:21
So it's really cool. You don't have to do the callback spaghetti as you have in in JavaScript You can use asyncio with async await syntax and it even looks nice and you do not see much of a difference with Normal request handler like you have in flask or tornado or Django you just put a wait and it's perfect any more questions
22:45
Ah, that's a oh Yes So I'm using web sockets for a trading application and it's the bandwidth is it's using is about maybe one or two megabit bits per second not megabytes and
23:05
I find that the library I use is consuming up to like 25% CPU just to pass messages What library do you use? I think it's web socket dash clients But do you find that is normal or I have to be honest
23:22
I never used the web sockets library because that's all you need to write the web sockets connection This is ten lines or something. So I know that in the old days When the web sockets have been just introduced you had a lot of browser introduced in Internet Explorer that did not support it Then you had to use something like socket IO that would fall back to long polling
23:41
And if it that doesn't work it for the fall back to Ajax requests. Yes, but these days are gone That's it. All of the browsers including IE I think since Python clients Okay, which name again
24:07
I mean that you can just use the standard testing here with the web sockets library That's what I was using when I was experimenting in production. I use tornado
24:22
Always for web sockets because it has other things that the web browser that the web server needs like templates Sessions and so on but if you just need pure web sockets and the web sockets library is okay I never seen any CPU or memory issues with it to be honest it
24:41
Yeah, it could be that the library is outdated but at the end if you're using web sockets with async IO Something that would cause you Load and your resources would be async IO and it's optimized quite well now So I don't think that you will encounter any problem with that. Okay. Thanks. Welcome
25:12
Yes, sure rest API's are using the The HTTP so with that you automatically when you're writing the rest clients
25:22
You can first of all rely on the status codes as I said that if you do in a request and it returns you Any number in the status that begins with four you can understand that you are doing something wrong with your requests It would be probably parameters. You forgot something in your parameters or you didn't authenticate That's another status code actually, but restful API's are not always implementing it. So like
25:46
just having Default responses can already give you some hints on what you're doing wrong and what you're doing, right? Like if you get response to hundred status means everything is perfect on web sockets. You don't have it So let's say you receive a web socket message. Okay?
26:04
That's probably good. But the fact is that you do not even Need to receive any message because when you send the web sockets message to the back end, there is no response by default Only if the server wants to send you something back You will know if it even works or not
26:21
Like here you just sent cats to me and the only way you know that it's there is by seeing it on the page Meaning that the whole loop worked in the restful API's you would see in the shell over there on the right red Red signs like you know When when something on the HTTP goes wrong the debugger tells you automatically
26:42
Like on this line in this file or in this connection something is bad in web sockets. You don't have it You have to debug everything by yourself. You have to understand everything by yourself The browser knows nothing about your communication and that's the first and I think the biggest difference and difficulties in building API's In using web sockets and using restful approach and secondly
27:02
It's just hard to compare it because that's two totally different partings I'm just comparing now from the technical side like exactly the protocol and implementation, but in general like you can also think on the web sockets when you Reconnected to this page like did the page reloads
27:21
What I have to do here is send one message for each object over there in the restful API You would usually send them all at once like one big thing and the big difference is that you could cache it With restful API's here you can't so it's kind of different approaches The web sockets are really tailored to be one by one communication. So I'm sending everything to everyone. I cannot cache it
27:46
That's another thing. Yeah, I mean we can discuss it for a really long time because restful and web sockets are two different sites At this point, but I think that these are two main differences of a technical protocol perspective
28:01
Welcome one more question Is it does the web circuit can be based on the path of the server? It is. Yes, so to connect to web socket. This is the path that I'm using right now
28:21
WS is normal web sockets WSS is the secure web sockets kind of the HTTPS for web sockets And yes You can have different passes here and this would map in your application server to different handlers or endpoints that will be handling that
28:50
One You don't have it So again in HTTP requests if you didn't get requests and something is wrong with connection
29:03
Since get is always idempotent The browser knows that it can just repeat it and do it again again until it gets something in web sockets You don't and there is no success message or failure message. So you sent it network gun You don't know if it was delivered or not It's TCP so on the protocol level you do know
29:21
But you do not know if it was complete if it was successful and so on So this is yeah, it's a big difference. You don't have this you have to take care of it by yourself Yes, yes, but you have to implement it you have to implement it yourself, okay one more
29:46
Can you do No, you can't that's a quick one What's the point of using async if you don't get a response at all
30:00
So where's the async actually mattering? Well, thank you, yeah, but Thanks. Yeah. Well, there are many cases of using web sockets
30:21
Like first of all on the on the if we if you ask me about the async First of all think on the back ends on the back end side It's fully async you do not have an overhead of keeping the connection open as you have in the web sockets in sorry in long polling The protocol is tailored that way that you have minimal overhead of multiple connections
30:43
So with just minimal AWS machine you can easily solve the 10k connection problem It costs back and nothing and you can use the single threaded server like tornado or not JS to handle them and you can use a fancy async await syntax on Python. So even if you are not
31:01
using If you are not using it in a request response fashion Which you actually shouldn't do because it's totally up to you. You can just receive messages You do not have to send something back if it's let's say a tracking application You just want to get the positions of your items somewhere. You're just collecting them You're not sending anything back, but the way you are collecting them
31:23
Are asynchronous in the sense that the connection is open You do not do anything with that connection the data comes through and only when it comes through your code is triggered Just as you have on the HTTP connections as well if using the async or similar thing, but without the HTTP overhead
31:43
Okay, I think this ties up now Okay Coffee break. Okay. Yeah, ask me on the coffee break More questions. Thank you very much