
Network.framework: A modern alternative to sockets - pjmlp
https://developer.apple.com/videos/play/wwdc2018/715/
======
philo23
I think quite a few of the hyperbolic comments here haven't seen any of this
video and are just reacting to the title.

From what I can gather from watching this so far is, it just sounds like a
layer you can optionally choose to use on-top of sockets that manages things
like: TLS, multiple networks (4G/3G/Wi-Fi), DNS resolving, proxies, etc for
you so you don't need to write it all yourself from scratch every time.

Maybe I'm wrong about that, or maybe none of this is actually as hard as it
sounds in practice. But this seems like it might be atleast some what useful.

~~~
carlosrg
> I think quite a few of the hyperbolic comments

That's what you get from things like deprecating OpenGL and replacing it with
a non-multiplatform alternative: bad reputation. They should ask Microsoft if
it's easy to get rid of if once you have it.

~~~
_wmd
I'm not a graphics programmer, but everything I've read about OpenGL tells me
moving to Metal isn't some embrace/extend maneuver but more likely due to the
fact OpenGL is steaming ancient garbage. Kind of like the types who once
complained that MacOS wasn't built on X Window (chortle)

BSD sockets isn't a bastion of extensible interface design, it basically
amounts to one giant ioctl() in every operating system. Darwin has weird
escape hatches built into it (AF_SYSTEM) much like Linux netlink, and protocol
parameter documentation is strewn across 5+ man pages each documenting a
different set of magic value combinations for non-portably controlling some
part of the stack. TCP_USER_TIMEOUT? That's one of many, many Linux socket
options, but it's part of our precious so-portable socket interface we must
maintain forever!

OS X chooses to bury its system call interface too, it's always been
considered a private detail of the C library. I see no reason why socket() and
friends couldn't similarly be forgotten. If some clean 21st century redesign
of an ancient API has knock-on effects for the structure of code in open
source projects across the ecosystem, that's probably a good thing in the long
run. Progress never happens by hugging the past, especially when that past is
ugly and filled with horrors

Try not to look at this as "hey, MacOS is breaking precious UNIX", but more as
"hey look, why can't Bonjour+multipath TCP be a one liner on Linux too?"

~~~
IshKebab
OpenGL is certainly old and warty but it is nothing like X11.

I think people would be ok with Apple dropping OpenGL if they supported
Vulkan, but their motivation and desire to lock people into Apple-only APIs is
so obvious and transparent... Why would you support it?

At least Microsoft works with third parties and acknowledges the existence of
some standards. Apple are always like "Here is the Apple way. I mean, the way.
Because there is only Apple. Apple is the whole world and nothing else
exists."

~~~
anonfunction
Which makes sense from a business point of view. Obviously that doesn’t always
align with a hacker mindset but there is a reason Apple is worth almost a
trillion dollars.

~~~
donarb
Exactly, Apple has 1B devices that can run Metal on their GPUs, why shouldn't
they write their own library?

------
Yoric
Am I the only one whose first reaction to this is "Oh, great, yet another
manner in which my next application won't be cross-platform?"

My second reaction being: "Oh, well, I'll just make it a web app instead of a
native app."

 __edit __Rephrased the last sentence.

~~~
pjmlp
Not everyone cares about cross-platform, some developers rather specialize in
a given platform.

You can keep using sockets if that is your thing.

~~~
Yoric
> Not everyone cares about cross-platform, some developers rather specialize
> in a given platform.

True.

> You can keep using sockets if that is your thing.

For the moment, yes. However, as you know, earlier this week, Apple has
officially deprecated OpenGL and OpenCL, a few years after introducing a
competing (and admittedly suprerior) API. It is my understanding that Apple
has not attempted to get this replacement API standardized, nor to offer it on
any other platform. While it's hard to deduce from such a small sample, this
precedent does suggest that the days of sockets are numbered.

This would make the life of some of my colleagues quite more complicated, and
it would, in time, simply get rid of the macOS version of a number of existing
cross-platform applications whose authors have neither the time nor the energy
to rewrite the network layer.

~~~
pjmlp
Every effort to get rid of plain unsafe C APIs is a plus on my book.

Apple has enough business with developers that care about macOS experience,
not plain ports from other platforms.

When I buy a computer with a specific OS, I want the experience provided by
the OS APIs.

~~~
Yoric
I understand your point. I also dislike a lot these plain unsafe C APIs.

However, I am a developer. When I write an application, I only have so much
time to spend on ports. Anything that requires me to have different designs
for different platforms is bad for me. So, in the ideal case, we'll end up
with a few high-level cross-platform abstractions (which may actually share
Network.framework's API, for all I know) on top of networking, and everybody
will remain happy. In the worst case, we'll end up with bits of duct tape, or
simply with fewer macOS apps.

Also, even as a macOS user, most of the applications I use daily are cross-
platform: Firefox, Thunderbird, VSCode, my various compilers & interpreters &
debuggers, VLC, Gitter, Open Office, Terminal, games, etc. In fact, looking at
my recent applications, the only single-platform applications I seem to be
using are Keychain, SimpleComic, Instruments (the only one in the list to
particularly integrate with the OS), Notes, Calendar. I sometimes use Pages
and Keynote, both of which have nice UX, but the niceties don't strike me as
particularly OS-integrated.

As I mentioned above, everything that makes it harder for developers to add
macOS to their list of targets encourages them to not port their app to my
current OS of choice. I'm thinking of, well, many in the list above, including
games.

This is, I imagine, part of the reason why so many developers left single-
platform development for web development. At least, that's my reaction.

~~~
jexah
> This is, I imagine, part of the reason why so many developers left single-
> platform development for web development. At least, that's my reaction.

Spot on. You even gave an example of this: VSCode. If Microsoft is doing it,
you can bet loads of other people are.

------
Analemma_
This thread confuses and saddens me. What is with the absolutist compulsion
that every API and framework has to be cross-platform? Cross-platform APIs and
frameworks must, by necessity, paper over differences, exclude the possibility
of leveraging a particular platform's strengths, and target the lowest (i.e.,
worst) common denominator. Sometimes that's a good tradeoff! But _all_ the
time? To the point where we have to attack OS vendors for having the nerve to,
oh gosh, add a feature?

Taken to the extreme, this makes no sense. What's the point of even having
different operating systems if there's only one acceptable API? Do you guys
think operating systems can never be allowed to introduce a feature and
corresponding API call?

~~~
ben509
I think it's inexperience speaking, which is also why it's very dogmatic. If
you've seen how standards develop, they're usually taking many ideas like this
that have become popular and tweaking the specs to smooth out the differences.

The POSIX API is often called Berkley Sockets because a vendor, BSD, released
their API and it was widely adopted. ANSI C cobbled together existing C
compilers into a standard, and POSIX itself was trying to tame a huge mess of
Unices.

And even if the standards don't fully converge, you have standard libraries to
plaster over the differences. Everyone has to contend with weird Windows path
conventions and such, to the point where it's hardly even notable.

------
gok
See also the Network.framework-based netcat implementation [1]. Only a couple
hundred lines of code, complete with TLS and mDNS support.

[1]
[https://developer.apple.com/documentation/network/implementi...](https://developer.apple.com/documentation/network/implementing_netcat_with_network_framework)

------
shurcooL
I wonder how this can/will affect Go’s standard net package [0]. Will it be
able to take advantage of this new Network framework (on macOS)? Or is the
framework too high level for the low level primitives net exposes, and will
need a new separate API?

Also, personally, I suspect this is another hint of an upcoming transition to
ARM64-based Macs. They will only implement these new Apple-specific APIs, not
the legacy/deprecated ones like OpenGL.

[0] [https://godoc.org/net](https://godoc.org/net)

------
kccqzy
Raw sockets have been discouraged in iOS years ago. It doesn't do things like
waking up the radio, activating the on-demand VPN; it performs poorly when the
device is multihomed; and from the developer's perspective there is a lot more
code that needs to be written to support simple things like supporting both
IPv4 and IPv6 (with happy eyeballs etc). The writing has been on the wall for
years. I will not be surprised if a few years down the road Apple completely
removes the sockets API from iOS (though I'd be surprised if they do it on
macOS). I'd say good riddance to this outdated API. Your traditional desktop
and laptops can continue to use this legacy API for your traditional and
cross-platform apps, but iOS as a mostly consumption platform has no need for
it. Personally I'm glad that Apple is using the closed nature of the iOS
platform to delete legacy baggage and experiment with newer saner APIs that
meet the needs of the twenty first century.

I'd also say there's very little reason as a typical developer to write socket
code; just use a library provided by the platform or your language. When's the
last time you used the raw sockets API?

~~~
eps
> Raw sockets

This is an established term for IP-level sockets, of SOCK_RAW protocol type.
Probably not what you meant.

[http://man7.org/linux/man-pages/man7/raw.7.html](http://man7.org/linux/man-
pages/man7/raw.7.html)

~~~
kccqzy
Yes I mean using the sockets API instead of a higher level API.

------
minus7
This is a nice high-level API for (more) reliably handling networking, taking
a fair amount of load off developers having to implement it themselves. Of
course it would be nice to have an API like that available as cross-platform
library.

~~~
pepijndevos
What about ZMQ?

~~~
jen20
ZMQ is not a 'neutral carrier' and can't interoperate with things not
implementing the protocol. It's great for the intended use case, but it's not
a general purpose replacement for the Berkely Sockets API.

~~~
devxpy
Maybe, but it works really well for most applications, and its available on
almost every language you can use.

~~~
jen20
I agree - it's a great tool and useful for a lot of things. However, it's not
useful as a general purpose network stack, which is what Network.framework is.

~~~
devxpy
I saw it has a C API, if someone made bindings, that would be nice

------
ratsimihah
Why does Apple have to make everything proprietary? It's kinda annoying.

~~~
pjmlp
Like any other OS vendor you mean.

~~~
Sir_Cmpwn
You mean "like one and only one other OS vendor"

~~~
pjmlp
Like Microsoft, IBM, Oracle, Sony, Nintendo, Google, ARM, Green Hills, PTC,
Unisys, DDC-I, MicroEJ, Blackberry, SAFERTOS, ....

~~~
shittyadmin
To be fair, when it comes to sockets, pretty much every OS' interface is
identical, all taken from BSD.

~~~
dialogbox
Most OS also have platform specific extension over standard apis. This is the
same category. They will not(and can not) deprecate BSD socket. Posix and BSD
socket are totally different from OpenGL/CL. It's just an additional api for
one who want to have maximum control.

------
danmg
I'm still waiting for OpenTransport to take off...

~~~
mypalmike
Haha, nice. I immediately thought of OpenTransport when I saw the headline. I
wonder how many developers actually wrote code directly against that API.

~~~
danmg
Outside of Apple? Probably not many directly. I do remember them sending out
developer kits for it though.

------
carlosrg
So will BSD sockets follow OpenGL's path to deprecation?

~~~
pieterr
As long as Apple wants to keep macOS POSIX-compliant, the sockets remain.

[1]
[https://images.apple.com/media/us/osx/2012/docs/OSX_for_UNIX...](https://images.apple.com/media/us/osx/2012/docs/OSX_for_UNIX_Users_TB_July2011.pdf)

~~~
kevin_b_er
From your link:

    
    
      * Open source UNIX foundation 
      ** Support for multiple CPU and GPU cores via Grand Central Dispatch and OpenCL
      * Comprehensive UNIX user environment 
      ** Standards-based graphics built on PDF (Quartz), OpenGL, and H.264 (QuickTime)
    

Your 2011/2012 document gives less assurance towards any future POSIX
compliance.

------
superbaconman
I love this! These are great ideas. Plans for more languages?

------
nyxtom
Not open source, don't care. Open standards matter.

~~~
MBCook
What’s the point of this comment?

It’s an Apple library for an Apple platform, to make things easier for people
using Swift/Objective-C.

Some people care about that.

Just because it’s not an open standard t shouldn’t be discussed?

~~~
jen20
Unfortunately it seems that many people cannot distinguish between the
programming model of sockets and the protocols that programming model exposes.

From what I can tell, Network.framework is a different API still talking TCP,
UDP and so forth underneath.

------
foxhill
i do not understand what incentive there is for anyone to use this - after
apple's deprecation of a standard they themselves conceived only 9 years ago
[1]. Berkley sockets might not be the conceptually best approach, but their
support is damn near universal.

[1] - [https://www.khronos.org/opencl/](https://www.khronos.org/opencl/)

~~~
WoodenChair
There are thousands of developers who make the choice to write apps for only
one platform. They now have a better networking library. What don't you get
about that? Not everyone chooses to write cross-platform. For people who don't
write cross-platform apps, why would they ever want to use sockets instead of
this much easier to use API?

~~~
foxhill
the cross platform bit was a little disingenuous of me. what i was really
trying to say was that in 9 years time from now, apple could deprecate it at
the drop of a hat. sockets, on the other hand, are likely not going anywhere,
and also have the benefit of existing everywhere, as they have for a long
time.

------
tzahola
You can use BSD sockets through the regular POSIX I/O API (read, write,
select, etc.). I wonder if the same holds for Network.framework sockets and
libdispatch I/O? Are they composable?

~~~
ben509
Network.framework seems to depend heavily on state notifications, which the
POSIX API doesn't support.

~~~
tzahola
I think you misunderstood my comment.

I was asking whether Network.framework sockets can be used via functions like
“dispatch_read”, analogously to how you can plug BSD sockets into POSIX I/O
functions as file descriptors.

------
stefan_
Skeleton crew on OSX but they have time to reinvent sockets. Apple, 2018.

~~~
saagarjha
What makes you think nobody is working on macOS? I really feel that macOS got
_more_ focus than iOS this year.

------
zaro
Let's see how long until they deprecate BSD sockets.

------
baybal2
Disingenious. A better way to say is that their particular socket
implementation was inferior to their new proprietary API. There is nothing
with socket paradigm as such that gives it inherent performance disadvantage.

~~~
doctorsher
I disagree. As discussed in the talk, Network.framework is built on top of
their userspace networking stack. This eliminates the kernel-userspace context
switch and gets rid of one packet copy operation. These are known problems in
the socket paradigm, at least as it exists in Linux and every BSD.

~~~
int0x80
Where do they say their network stack is userspace? I watched the video but
the last 10 minutes and I missed it.

~~~
doctorsher
The userspace networking portion of the talk starts at 46:00.

To clarify, the whole networking stack isn't userspace. They still have the
classical BSD networking stack. I think the userspace networking stack is used
automatically by system libraries like URLSessions and this new
Network.framework library. They introduced their userspace networking stack
during last year's WWDC:
[https://developer.apple.com/videos/play/wwdc2017/707](https://developer.apple.com/videos/play/wwdc2017/707)

~~~
int0x80
Ah, good. Thank you.

