Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Upcoming presentations on asynchronous network programming

50 views
Skip to first unread message

Richard

unread,
Feb 15, 2023, 3:54:56 PM2/15/23
to
[Please do not mail me a copy of your followup]

Over the next few months, I'll be doing some presentations on network
programming. The presentations will be virtual and uploaded to
YouTube afterwards. You can see them in the Utah C++ Programmers
meetup group here: <https://www.meetup.com/utah-cpp-programmers/> in
the 'Events' tab:

- Getting Started with Boost.Asio: Timers and Serial Ports (March)
- TCP/IP Networking with Boost.Asio (April)
- Basic HTTP and WebSocket Programming with Boost.Beast (May)
- C++ Promises/A+ library in the Javascript style (June)

--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

Richard

unread,
Feb 15, 2023, 3:59:21 PM2/15/23
to
[Please do not mail me a copy of your followup]

(Richard) legaliz...@mail.xmission.com spake the secret code
<tsjgqf$3ubfr$1...@news.xmission.com> thusly:

>Over the next few months, I'll be doing some presentations on network
>programming. [...]

Past presentations on YouTube:
<https://www.youtube.com/@UtahCppProgrammers>

Mut...@dastardlyhq.com

unread,
Feb 16, 2023, 4:12:29 AM2/16/23
to
On Wed, 15 Feb 2023 20:54:39 -0000 (UTC)
legaliz...@mail.xmission.com (Richard) wrote:
>[Please do not mail me a copy of your followup]
>
>Over the next few months, I'll be doing some presentations on network
>programming. The presentations will be virtual and uploaded to
>YouTube afterwards. You can see them in the Utah C++ Programmers
>meetup group here: <https://www.meetup.com/utah-cpp-programmers/> in
>the 'Events' tab:
>
>- Getting Started with Boost.Asio: Timers and Serial Ports (March)
>- TCP/IP Networking with Boost.Asio (April)
>- Basic HTTP and WebSocket Programming with Boost.Beast (May)

Boost? *gag* Who uses it now anyway given C++17 does everything useful that
it used to do bar a few specialised maths algos?

Plus the standard C sockets API is fairly simple so why you'd need it wrapped
up in that outdated library is anyones guess.

Whatever happened to the ACE library?

>- C++ Promises/A+ library in the Javascript style (June)

Javascript style? You've got to be f*cking kidding.


Paavo Helde

unread,
Feb 16, 2023, 4:52:20 AM2/16/23
to
16.02.2023 11:12 Mut...@dastardlyhq.com kirjutas:
> On Wed, 15 Feb 2023 20:54:39 -0000 (UTC)
> legaliz...@mail.xmission.com (Richard) wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Over the next few months, I'll be doing some presentations on network
>> programming. The presentations will be virtual and uploaded to
>> YouTube afterwards. You can see them in the Utah C++ Programmers
>> meetup group here: <https://www.meetup.com/utah-cpp-programmers/> in
>> the 'Events' tab:
>>
>> - Getting Started with Boost.Asio: Timers and Serial Ports (March)
>> - TCP/IP Networking with Boost.Asio (April)
>> - Basic HTTP and WebSocket Programming with Boost.Beast (May)
>
> Boost? *gag* Who uses it now anyway given C++17 does everything useful that
> it used to do bar a few specialised maths algos?

Is this a trick question? From where exactly do you think major portions
of enhancements to the C++ standards have come over the last 20 years?
C++17 *is* halfway Boost, even when renamed std::.

To answer the obvious, one currently uses Boost libraries when one needs
the functionality and the particular library is not yet included in C++
standards. Like Boost.asio.

>
> Plus the standard C sockets API is fairly simple so why you'd need it wrapped
> up in that outdated library is anyones guess.

Please code up a scalable, portable, TLS-capable HTTP server in C++
without using any third-party libraries, then come back again. We might
be still here.

About "outdated": the last version of boost came out exactly 2 months
ago, including 37 listed enhancements and fixes in Boost.asio.

> Whatever happened to the ACE library?

Whatever that is, it seems to be not included in C++ standards either.

Mut...@dastardlyhq.com

unread,
Feb 16, 2023, 5:08:08 AM2/16/23
to
On Thu, 16 Feb 2023 11:52:03 +0200
Paavo Helde <ees...@osa.pri.ee> wrote:
>16.02.2023 11:12 Mut...@dastardlyhq.com kirjutas:
>> On Wed, 15 Feb 2023 20:54:39 -0000 (UTC)
>> legaliz...@mail.xmission.com (Richard) wrote:
>>> [Please do not mail me a copy of your followup]
>>>
>>> Over the next few months, I'll be doing some presentations on network
>>> programming. The presentations will be virtual and uploaded to
>>> YouTube afterwards. You can see them in the Utah C++ Programmers
>>> meetup group here: <https://www.meetup.com/utah-cpp-programmers/> in
>>> the 'Events' tab:
>>>
>>> - Getting Started with Boost.Asio: Timers and Serial Ports (March)
>>> - TCP/IP Networking with Boost.Asio (April)
>>> - Basic HTTP and WebSocket Programming with Boost.Beast (May)
>>
>> Boost? *gag* Who uses it now anyway given C++17 does everything useful that
>> it used to do bar a few specialised maths algos?
>
>Is this a trick question? From where exactly do you think major portions
>of enhancements to the C++ standards have come over the last 20 years?
>C++17 *is* halfway Boost, even when renamed std::.

I know. C++ took the good bits and left the junk behind. Also when something
is built into the language rather than being a load of hacky macros mixed with
playing silly buggers with the template system it tends to work a lot better.

>To answer the obvious, one currently uses Boost libraries when one needs
>the functionality and the particular library is not yet included in C++
>standards. Like Boost.asio.

Why does it need to be in C++ when theres the O_NONBOCK & O_ASYNC sockets flag
not to mention select() and poll()?

>> Plus the standard C sockets API is fairly simple so why you'd need it wrapped
>
>> up in that outdated library is anyones guess.
>
>Please code up a scalable, portable, TLS-capable HTTP server in C++
>without using any third-party libraries, then come back again. We might
>be still here.

I don't have a problem with 3rd party libraries, I have a problem with Boost.
For HTTP any sane person would use Curl though frankly openSSL is fairly
simple to use and basic HTTP is easy to implement - I've done it.

>About "outdated": the last version of boost came out exactly 2 months
>ago, including 37 listed enhancements and fixes in Boost.asio.
>
>> Whatever happened to the ACE library?
>
>Whatever that is, it seems to be not included in C++ standards either.

It was a C++ networking (and a few other things) library that was briefly
popular in the 2000s. But it had little advantage over just using the sockets
API directly.

Paavo Helde

unread,
Feb 16, 2023, 5:33:45 AM2/16/23
to
16.02.2023 12:07 Mut...@dastardlyhq.com kirjutas:

> openSSL is fairly simple to use

I see. I currently have a task to encode Diffie-Hellman parameter
generation with openssl library calls (as opposed to the command-line).
I'm sure it's simple if one knows how to do it, which I unfortunately don't.

Mut...@dastardlyhq.com

unread,
Feb 16, 2023, 11:21:36 AM2/16/23
to
Most people use it as a higher level sockets library but whatever floats
your boat.

Scott Lurndal

unread,
Feb 16, 2023, 11:58:27 AM2/16/23
to
I would disagree with that charactization. Pretty much every time I've
used openssl over the last two decades has been for access to the
crypto functionality (and the fact that openssl can be configured
to off-load to crypto hardware if available is a bonus), not for Transport
Level Security.

Mut...@dastardlyhq.com

unread,
Feb 16, 2023, 12:07:04 PM2/16/23
to
I suspect your use case is rather uncommon.

Bonita Montero

unread,
Feb 16, 2023, 10:15:34 PM2/16/23
to
Am 16.02.2023 um 10:12 schrieb Mut...@dastardlyhq.com:

> Plus the standard C sockets API is fairly simple so why you'd
> need it wrapped up in that outdated library is anyones guess.

Boost.ASIO is usually more performant than manual socket calls
and easier to use.


Richard

unread,
Feb 17, 2023, 12:40:55 AM2/17/23
to
[Please do not mail me a copy of your followup]

Mut...@dastardlyhq.com spake the secret code
<tsks1c$376qb$1...@dont-email.me> thusly:

>[a bunch of hand-waiving statements that are not informed by
>the current reality of network programming in C++ or the current
>state of the ISO C++ standard]

Troll much?

Neither C++17, C++20 nor C++23 has any standard library support for
networking.

C++ Weekly Episode 345: No Networking in C++20 or C++23
<https://www.youtube.com/watch?v=v6m70HyI0XE>

Standard library support for serial ports has never been proposed AFAIK.

Writing a network aware application is much, much more than just
saying "give me a socket" (despite what the show "24" may have led you
to believe). A socket is just providing the transport mechanism and
that's just the start of your troubles. From there you have to implement
some sort of protocol on top of the transport. On top of that
protocol you have to implement some meaningful application semantics.

Utah C++ Programmers has already given presentations on other networking
libraries for implementing a REST API on top of application data structures.
You can view those presentations on our Network Programming playlist:
<https://www.youtube.com/playlist?list=PLJDO7P5jAoXzQvuy7UjFoDSdSy_FLqfOf>

But hey, spend 5 years coding up something similar on raw sockets with
a C API if you like. Nobody is *making* you use a higher-level library.

Mut...@dastardlyhq.com

unread,
Feb 17, 2023, 4:33:21 AM2/17/23
to
Who knows in Windows, but on *nix it'll simply be using the socket API under
the hood for networking so that will not be the case.

>and easier to use.

Unlikely. The main parts of the sockets API are well designed and can be
used by dummies. The only awkward bits are the rather arcane types and
structures IMO.

Mut...@dastardlyhq.com

unread,
Feb 17, 2023, 4:39:03 AM2/17/23
to
On Fri, 17 Feb 2023 05:40:39 -0000 (UTC)
legaliz...@mail.xmission.com (Richard) wrote:
>[Please do not mail me a copy of your followup]
>
>Mut...@dastardlyhq.com spake the secret code
><tsks1c$376qb$1...@dont-email.me> thusly:
>
>>[a bunch of hand-waiving statements that are not informed by
>>the current reality of network programming in C++ or the current
>>state of the ISO C++ standard]

Where did I write that?

>Troll much?

I think that might be you.

>Neither C++17, C++20 nor C++23 has any standard library support for
>networking.

I'm quite well aware of that.

>Standard library support for serial ports has never been proposed AFAIK.

Wow, thanks for the heads up there.

>Writing a network aware application is much, much more than just
>saying "give me a socket" (despite what the show "24" may have led you
>to believe). A socket is just providing the transport mechanism and

Wtf are you babbling about? Wtf is "24"?

>that's just the start of your troubles. From there you have to implement
>some sort of protocol on top of the transport. On top of that
>protocol you have to implement some meaningful application semantics.

No shit. Do you expect ethernet cards to be able to speak HTTP?

>Utah C++ Programmers has already given presentations on other networking
>libraries for implementing a REST API on top of application data structures.

Oh fuck off with your REST web shit. It has no place in the sockets API which
is to write all that low level code web script kiddies take for granted.

>You can view those presentations on our Network Programming playlist:
><https://www.youtube.com/playlist?list=PLJDO7P5jAoXzQvuy7UjFoDSdSy_FLqfOf>

No thanks.

>But hey, spend 5 years coding up something similar on raw sockets with
>a C API if you like. Nobody is *making* you use a higher-level library.

Someone has to write the low level code or do you think it writes itself?
Also do you know what raw sockets are used for? No, didn't think so.
Hint - they're not the same as TCP, UDP or SCTP sockets.

Bonita Montero

unread,
Feb 17, 2023, 5:16:21 AM2/17/23
to
Am 17.02.2023 um 10:33 schrieb Mut...@dastardlyhq.com:

> Unlikely. ...

You've never used it. Socket-Classes are always easier to use.

red floyd

unread,
Feb 17, 2023, 2:40:25 PM2/17/23
to
On 2/17/2023 1:38 AM, Mut...@dastardlyhq.com wrote:
> On Fri, 17 Feb 2023 05:40:39 -0000 (UTC)

>> Writing a network aware application is much, much more than just
>> saying "give me a socket" (despite what the show "24" may have led you
>> to believe). A socket is just providing the transport mechanism and
>
> Wtf are you babbling about? Wtf is "24"?
TV show starring Kiefer Sutherland. Anytime they needed to do something
computer related on that show, they had someone "open a socket".

Chris M. Thomasson

unread,
Feb 17, 2023, 3:31:47 PM2/17/23
to
Never used it. However I am guessing that it uses IOCP on windows, which
I have used quite a bit back in the day. Also on Linux it must be using aio?

Chris M. Thomasson

unread,
Feb 17, 2023, 3:35:27 PM2/17/23
to
lol.

Richard

unread,
Feb 17, 2023, 4:39:06 PM2/17/23
to
[Please do not mail me a copy of your followup]

Welcome to my KILL file.

Mut...@dastardlyhq.com

unread,
Feb 18, 2023, 6:19:20 AM2/18/23
to
Sounds like one of the writers spent 2 mins with a dev. Still, sometimes they
do ok such as in jurassic park.

0 new messages