Can't find unit unixsockets

[MarkMLl]

I think you meant protocol family.

You are of course quite right.

Apropos _DGRAM vs _STREAM: more to the point, unix(7) says that both are acceptable, albeit with a couple of protocol caveats... and I'd need to think hard about some of the things I've used it for. However in the current case I thing it's best to focus on the "dgram vs stream" rather than "connected vs unconnected" aspect, since if you're passing block data around (i.e. FDs) you really do need datagrams.

Edit: Forgot to thank you for your pipe code; thanks.

You're welcome, I grabbed it in a hurry but forgot to check the dgram vs stream aspect... that might actually have all been streams since I was handling piped (etc.) data from a logic analyser to convert it into a standard format (and had checked the various channels fairly thoroughly).

MarkMLl

[TCH]

Apropos _DGRAM vs _STREAM: more to the point, unix(7) says that both are acceptable, albeit with a couple of protocol caveats... and I'd need to think hard about some of the things I've used it for. However in the current case I thing it's best to focus on the "dgram vs stream" rather than "connected vs unconnected" aspect, since if you're passing block data around (i.e. FDs) you really do need datagrams.

So, that's why SOCK_STREAM did not worked: no blocks, just a stream of bytes without any particular meaning. Thanks, for pointing out.

[MarkMLl]

So, that's why SOCK_STREAM did not worked: no blocks, just a stream of bytes without any particular meaning. Thanks, for pointing out.

Probably, or at the very least blocks getting merged arbitrarily. That's one reason why, when it was still unclear what you were doing, I threw SCTP into the mix: it's somewhat (!) more complex ("designed by committee" is the phrase that springs to mind), but offers reliable block delivery over a network (provided that the in-path routers etc. support it, which is rare).

I've realised that I missed out some very juicy stuff from the example code I C&Ped yesterday, and am about to go back and extend it.

MarkMLl

[TCH]

So, that's why SOCK_STREAM did not worked: no blocks, just a stream of bytes without any particular meaning. Thanks, for pointing out.

Probably, or at the very least blocks getting merged arbitrarily. That's one reason why, when it was still unclear what you were doing, I threw SCTP into the mix: it's somewhat (!) more complex ("designed by committee" is the phrase that springs to mind), but offers reliable block delivery over a network (provided that the in-path routers etc. support it, which is rare).

No, i've never worked with SCTP. As a matter of fact, i did not even ever heard of it, but after a quick search, i think i am not alone with that: it is not very widespread.

I've realised that I missed out some very juicy stuff from the example code I C&Ped yesterday, and am about to go back and extend it.

I think you should make a unit of it and commit it into the FPC RTL, or publish it in your repo.

[PascalDragon]

So, that's why SOCK_STREAM did not worked: no blocks, just a stream of bytes without any particular meaning. Thanks, for pointing out.

Probably, or at the very least blocks getting merged arbitrarily. That's one reason why, when it was still unclear what you were doing, I threw SCTP into the mix: it's somewhat (!) more complex ("designed by committee" is the phrase that springs to mind), but offers reliable block delivery over a network (provided that the in-path routers etc. support it, which is rare).

No, i've never worked with SCTP. As a matter of fact, i did not even ever heard of it, but after a quick search, i think i am not alone with that: it is not very widespread.

It's more widespread than you might realize, cause it's one of the core protocols used by WebRTC which is supported by all modern browsers and other applications that use WebRTC to provide peer-to-peer communication.

[TCH]

Perhaps the found topics and articles were too old.

[MarkMLl]

It's more widespread than you might realize, cause it's one of the core protocols used by WebRTC which is supported by all modern browsers and other applications that use WebRTC to provide peer-to-peer communication.

In fairness, /can/ be used by would be a better way of putting it. It works peer-to-peer on a local LAN, it works over a tunnel provided that the relevant ISPs are competent ** , but IME is not at all well-supported across commodity routers and firewalls.

It's definitely got its good points, but an "SCTP lite" which offered reliable datagram transmission (i.e. like UD sockets but between systems) would go down well.

** Which is a strong argument for end-to-end encryption: if intermediate carriers can't see what's in there they aren't likely to try to filter it.

MarkMLl

[duralast]

No, i've never worked with SCTP. As a matter of fact, i did not even ever heard of it, but after a quick search, i think i am not alone with that: it is not very widespread.

The Stream Control Transmission Protocol (SCTP) was originally designed by the Signaling Transport (SIGTRAN) group of IETF for Signalling System 7 (SS7) transport over IP-based networks. It is a reliable transport protocol operating on top of an unreliable connectionless service, such as IP.

More info on SCTP is available in the Oracle Help Center at https://docs.oracle.com/cd/E95618_01/html/sbc_scz810_acliconfiguration/GUID-8D95AA21-4530-4E02-90FB-032E3856CC80.htm

[TCH]

Thanks, i'll read it.

[PascalDragon]

It's more widespread than you might realize, cause it's one of the core protocols used by WebRTC which is supported by all modern browsers and other applications that use WebRTC to provide peer-to-peer communication.

In fairness, /can/ be used by would be a better way of putting it. It works peer-to-peer on a local LAN, it works over a tunnel provided that the relevant ISPs are competent ** , but IME is not at all well-supported across commodity routers and firewalls.

I can personally attest that it works rather well if it's set up correctly. We use it in one of our products at work to provide remote VNC in the browser. As long as one side is not connected to a symmetric NAT it will most likely be able to establish a connection using hole punching and otherwise a TURN relay will be used. This is completely transparent to the user of WebRTC (and it will use SCTP in any case, because the WebRTC suite is based on UDP sockets and thus needs something(TM) to make it reliable).

It's definitely got its good points, but an "SCTP lite" which offered reliable datagram transmission (i.e. like UD sockets but between systems) would go down well.

Then you might want to take a look at QUIC.