It's not actually a complicated though. Just try to write something using boost::asio and then imagine that standard C++ asio will be better (you might not feel that much pain when boost requires handlers to be CopyConstructible, but it's a hell of a pain).
@@thevinn I wish that were to be true, but boost still requires CopyConstructible: www.boost.org/doc/libs/1_70_0/doc/html/boost_asio/overview/cpp2011/move_handlers.html ("However, handler types are still required to be copy constructible")
Another great talk from Vinnie. With the networking TS and Beast I would not be surprised to see C++ taking some place from Erlang in realtime communication. Thanks to Vinnie for making this library available to us.
That was quite a rich talk and just what I was looking for. I was really confused with the examples online. That transfer of ownership paradigm with the shared from this was very unintuitive to me. I like the JavaScript lessons and how everyone was so amazed at how easily it was to do the client socket in a higher level language.
When i first time used asio, i have a session object that handle 2 sockets (2 strand). If one of the sockets closed, i couldn't immediately free the session since the other socket still using share states in their complete hanlde (run async on other thread). I didn't know how to syn this so i made a deadline timmer to let everything clean up before deletion. It is really bad design, but would be easier if i used share pointers. i'm newbie so still have to learn more.
around 20:40) I think `while(N--)` should be `while(--N)`, since the intent is making the vector contain N-1 threads, not N threads. Anyway, thanks for the wonderful talk!
Amazing presentation. It requires multiple listen to fully grasp the full extent which is really necessary to mast low level websocket in C++. Curious about Beast alternate implementation and how they fare in terms of performance / ease of use.
I would really like a talk about Boost.Beast with the Networking TS and the Coroutines TS. If there isn't one, I think we will all get too comfortable with JavaScript async/await. C++ needs coroutines here to simplify the lifetime of the state, not just the control flow, using an allocator that allocates out of a a std::array in the coroutine frame. It would be nice if someone would make this not-yet-done talk.
Why does ConstBufferSequence require CopyConstructible instead of just MoveConstructible? How many coexistent copies does the write method create internally?
Well, consider an operation X on a buffer sequence which is expressed in terms of two or more calls to operation Y which operates on a subset of the buffer sequence. If this operation X is invoked on a buffer sequence that only supports MoveConstructible, then ownership of the buffer sequence would transfer to the first invocation of operation Y. At this point operation Y could not be invoked again, because operation X no longer has ownership of the buffer sequence (it is in the moved-from state).
@@thevinn A ConstBufferSequence is just a pointer and a size. Why can't X construct its own move-only view of the same values (e.g. via the overload `const_buffer buffer(const const_buffer & b)`) to pass to Y? As it is requiring CopyConstructible, it doesn't mind constructing a new ConstBufferSequence.
Could someone please explain to me the reasons of the reoccurring Javascript bashing here at cppcon talks? Or how should it be understood if not bashing? Is it just a popular humorous handling of other languages in general, more like a running gag? But if I should keep my hands away from JavaScript in productive code, for what reasons and what's the better alternative?
Well, I wouldn't go so far as calling it "bashing" but the level of expertise required to learn and use JavaScript is far lower than that required to learn and use C++. As a consequence, there are many more JavaScript programmers than there are C++ programmers. Correspondingly, there are many more BAD JavaScript programmers than there are bad C++ programmers. JavaScript is also harder to maintain as the size of the program increases. This doesn't mean that large C++ programs are automatically more maintainable, but C++ gives you more tools to keep software entropy down. In particular, the type system in C++ is quite robust. I'm not making a value judgement here, each language has its own strengths and weaknesses. As you can see from watching my talk, JavaScript let me put up a GUI and implement a multi-user chat client very quickly, with a tiny amount of code. JavaScript definitely has its place we just need to make sure that we are using it for the right things. And of course JavaScript made the two authors I profiled in my talk quite rich, so who can really argue against it? :)
Also, keep in mind that, quoting bjarne: "There are only two kinds of languages: the ones people complain about and the ones nobody uses." There is also a lot of complaining about C++ out there, and they are, sometimes :) , not wrong.. it is what it is, it's big, it's complicated, there are good parts, there are not so good parts.. but ppl get things up and running in the real world right now (while complaining non-stop about it (referring to some coworkers)). I guess the same can be said for JavaScript
The problem is that this is just using the 1970ths old socket API, so it's boring 50 year old stuff. With 40 or 100GBit Network adapters, the Berkley Socket API is just not useable anymore. Once 20 years ago there was talk about 10K program now it's 10M. Do research but we will pull out the whole networking api into user space and assign threads direct to them as handlers. There will be a lot of software changes to make this scale.
Just because something is old doesn't mean it's bad. There's nothing boring about UNIX sockets - it's run the internet and stuff that predated the internet since decades. Even if you did invent something better, were stuck with sockets unless the new thing has a revolutionary benefit. You can build whatever abstractions you want over and above the sockets layer. The fact that agar.io is able to allow so many players, shows the efficiency of the system. This talk was just a demo to illustrate how to go about wrapping the lower level layer into a higher level API without losing efficiency and a primer of how to use asio
@@VivekNa Old == Inefficient for modern technology. The current API doesn't scale. Just use google, there are modern attempts. And i hope we get coroutines soon because they are absolutely required if you just have a few tens of nanoseconds for every frame. Like filesystems (i really fucking hate them) we really need to go away from the classic 50 year old unix design. But it's very hard to talk about this to people who are extremely conservative and blind for real world needs and advantages.
@@llothar68 Coroutines are a notational convenience they do not improve performance relative to callbacks. The Networking TS api scales just fine, plenty of companies are using them with fiber / 100GB backbones with custom drivers.
I think Qt5 websocket library seems easier to use (doc.qt.io/qt-5/qtwebsockets-simplechat-example.html does something similar to what is presented here). I would prefer it unless there is a strong need that my application has to use pure standard and boost
This is the best talk I've seen that spanned a lot of concepts in a clear way. 👏👏👏
Your talk was god-tier dude. The entire presentation was amazing, on every level.
Its wonderful to hear the voice of my wonderful Vinnie. My child prodigy and creator of Bear Share. I miss you so m u c h!
Really great video. So much content that I found myself having to frequently pause and go back to review. Powerfully simple.
Damn! Networking in C++ used to be complicated. Now everyone is going to know how to do that in relatively few lines of code.
Have no fear, we are far from removing the last remaining complexities from C++ :)
It's not actually a complicated though. Just try to write something using boost::asio and then imagine that standard C++ asio will be better (you might not feel that much pain when boost requires handlers to be CopyConstructible, but it's a hell of a pain).
@@vladyslav007 Boost.Asio only requires MoveConstructible handlers now, as of Boost 1.66.
@@thevinn I wish that were to be true, but boost still requires CopyConstructible: www.boost.org/doc/libs/1_70_0/doc/html/boost_asio/overview/cpp2011/move_handlers.html ("However, handler types are still required to be copy constructible")
That was worth a thousand pages of documentation, thank you!
printing money as we speak
Another great talk from Vinnie. With the networking TS and Beast I would not be surprised to see C++ taking some place from Erlang in realtime communication. Thanks to Vinnie for making this library available to us.
That was quite a rich talk and just what I was looking for. I was really confused with the examples online. That transfer of ownership paradigm with the shared from this was very unintuitive to me. I like the JavaScript lessons and how everyone was so amazed at how easily it was to do the client socket in a higher level language.
Great talk, super clear and Vinnie keeps it always interesting.
great material! thanks for your great work!
Thanks for all your great work, Vinnie.
30 seconds deadline for session deletion because i didn't want to use shared pointers. i learned something new today.
whut? Could you explain this please
When i first time used asio, i have a session object that handle 2 sockets (2 strand). If one of the sockets closed, i couldn't immediately free the session since the other socket still using share states in their complete hanlde (run async on other thread). I didn't know how to syn this so i made a deadline timmer to let everything clean up before deletion. It is really bad design, but would be easier if i used share pointers. i'm newbie so still have to learn more.
around 20:40) I think `while(N--)` should be `while(--N)`, since the intent is making the vector contain N-1 threads, not N threads.
Anyway, thanks for the wonderful talk!
Thanks for making this video! So helpful.
Amazing presentation. It requires multiple listen to fully grasp the full extent which is really necessary to mast low level websocket in C++. Curious about Beast alternate implementation and how they fare in terms of performance / ease of use.
**claps** great talk! love your code and libs Vinnie !
This technology gives me chills.
as in "I hope I won't ever have to use it cuz these apis with fncs like consume and commit suck ass?" or as in it's awesome?
spoke too soon, this talk gets better!!
I would really like a talk about Boost.Beast with the Networking TS and the Coroutines TS. If there isn't one, I think we will all get too comfortable with JavaScript async/await. C++ needs coroutines here to simplify the lifetime of the state, not just the control flow, using an allocator that allocates out of a a std::array in the coroutine frame.
It would be nice if someone would make this not-yet-done talk.
Nice, thank you
Great talk Vinnie.
Why does ConstBufferSequence require CopyConstructible instead of just MoveConstructible? How many coexistent copies does the write method create internally?
Well, consider an operation X on a buffer sequence which is expressed in terms of two or more calls to operation Y which operates on a subset of the buffer sequence. If this operation X is invoked on a buffer sequence that only supports MoveConstructible, then ownership of the buffer sequence would transfer to the first invocation of operation Y. At this point operation Y could not be invoked again, because operation X no longer has ownership of the buffer sequence (it is in the moved-from state).
@@thevinn A ConstBufferSequence is just a pointer and a size. Why can't X construct its own move-only view of the same values (e.g. via the overload `const_buffer buffer(const const_buffer & b)`) to pass to Y? As it is requiring CopyConstructible, it doesn't mind constructing a new ConstBufferSequence.
Could someone please explain to me the reasons of the reoccurring Javascript bashing here at cppcon talks? Or how should it be understood if not bashing? Is it just a popular humorous handling of other languages in general, more like a running gag? But if I should keep my hands away from JavaScript in productive code, for what reasons and what's the better alternative?
Well, I wouldn't go so far as calling it "bashing" but the level of expertise required to learn and use JavaScript is far lower than that required to learn and use C++. As a consequence, there are many more JavaScript programmers than there are C++ programmers. Correspondingly, there are many more BAD JavaScript programmers than there are bad C++ programmers. JavaScript is also harder to maintain as the size of the program increases. This doesn't mean that large C++ programs are automatically more maintainable, but C++ gives you more tools to keep software entropy down. In particular, the type system in C++ is quite robust.
I'm not making a value judgement here, each language has its own strengths and weaknesses. As you can see from watching my talk, JavaScript let me put up a GUI and implement a multi-user chat client very quickly, with a tiny amount of code. JavaScript definitely has its place we just need to make sure that we are using it for the right things. And of course JavaScript made the two authors I profiled in my talk quite rich, so who can really argue against it? :)
Also, keep in mind that, quoting bjarne: "There are only two kinds of languages: the ones people complain about and the ones nobody uses." There is also a lot of complaining about C++ out there, and they are, sometimes :) , not wrong.. it is what it is, it's big, it's complicated, there are good parts, there are not so good parts.. but ppl get things up and running in the real world right now (while complaining non-stop about it (referring to some coworkers)). I guess the same can be said for JavaScript
@@frydac Hah, love it! Bjarne, ever so pragmatic!
Great talk.
it is 2022 and still no standardized networking in c++
The problem is that this is just using the 1970ths old socket API, so it's boring 50 year old stuff. With 40 or 100GBit Network adapters, the Berkley Socket API is just not useable anymore. Once 20 years ago there was talk about 10K program now it's 10M. Do research but we will pull out the whole networking api into user space and assign threads direct to them as handlers. There will be a lot of software changes to make this scale.
Just because something is old doesn't mean it's bad. There's nothing boring about UNIX sockets - it's run the internet and stuff that predated the internet since decades. Even if you did invent something better, were stuck with sockets unless the new thing has a revolutionary benefit.
You can build whatever abstractions you want over and above the sockets layer. The fact that agar.io is able to allow so many players, shows the efficiency of the system.
This talk was just a demo to illustrate how to go about wrapping the lower level layer into a higher level API without losing efficiency and a primer of how to use asio
@@VivekNa Old == Inefficient for modern technology. The current API doesn't scale. Just use google, there are modern attempts. And i hope we get coroutines soon because they are absolutely required if you just have a few tens of nanoseconds for every frame.
Like filesystems (i really fucking hate them) we really need to go away from the classic 50 year old unix design. But it's very hard to talk about this to people who are extremely conservative and blind for real world needs and advantages.
@@llothar68 Coroutines are a notational convenience they do not improve performance relative to callbacks. The Networking TS api scales just fine, plenty of companies are using them with fiber / 100GB backbones with custom drivers.
great presentation ! too bad i don't use websocket stuff ;)
I think Qt5 websocket library seems easier to use (doc.qt.io/qt-5/qtwebsockets-simplechat-example.html does something similar to what is presented here). I would prefer it unless there is a strong need that my application has to use pure standard and boost
Nope 🙅🏻 Qt5 is bloated
"Every mutable buffer sequence is also a const buffer sequence. So that's that"
No wonder c++ is as dead as glam rock.