ObjFW  History of src/OFDDPSocket.m of d8ef56254dc71c16

This didn't work without problems on all OSes. Since ofatalkcfg is no
longer there, there is no reason to keep this for now. In the future, if
there is a more generic replacement for ofatalkcfg, this can just be
reverted. file: [0f90d0e13f] check-in: [550bd1b7bb] user: js, branch: trunk, size: 7539 [annotate] [blame] [check-ins using] [diff]

This seems to be an oddity limited to OSes that have implemented DDP
exclusively for netatalk, while macOS and Windows don't include it with
the data.

While on macOS it's possible to achieve the previous behavior via some
hacks, this is impossible on Windows, so the proper approach is to
handle it like everybody else: Specify the protocol type when binding
and only handle packets of the correct protocol type. file: [11bd6fb256] check-in: [9c2f20e736] user: js, branch: trunk, size: 7082 [annotate] [blame] [check-ins using] [diff]

This required quite some reverse engineering, as it is all completely
undocumented.

Receiving worked pretty much as expected: Do a readv() and get the raw
DDP packet including headers, then parse the headers ourselves to get
the source and fill out an OFSocketAddress.

But sending was tricky and required reading through kernel sources.
writev() does not work on a raw DDP socket and always fails with
EDESTADDRREQ, even if the destination address is provided as part of the
raw DDP packet. Meanwhile, sendmsg() always creates a DDP packet for us,
even in raw mode, and prepends the data with what it believes to be the
DDP protocol type (the protocol parameter passed to socket()). After
reading through the kernel source for some time to find a way to disable
this behavior, I found that you can set DDP_HDRINCL in ATPROTO_NONE to
provide your entire header to sendmsg() instead to work around this,
making it behave like you would expect from a writev() to a raw socket.

The only missing part now is to return a proper address a socket was
bound to, as currently it just leaves network and node at 0 and only
fills the port. This probably just requires some more reading of kernel
sources. file: [0702a801d8] check-in: [41535b41da] user: js, branch: trunk, size: 5781 [annotate] [blame] [check-ins using] [diff]

It seems that neither Windows nor macOS support DDP sockets, but only
the layers on top, while neither Linux nor NetBSD support the layers on
top, but only provide DDP.

It seems that DDP is not meant to be used directly, while Linux and
NetBSD only provide the minimum to use netatalk, which is DDP. ObjFW
would need to use the layers on top on Windows and macOS and implement
those layers itself on Linux and NetBSD. This also means that no code
would be shared between Linux / NetBSD and Windows / macOS, as it's
impossible to have one implementation that works for everything. At this
point, the effort required doesn't make sense. check-in: [0b4f713964] user: js, branch: trunk, size: 0