* AF_UNIX/AF_LOCAL
@ 2020-06-02 12:46 sten.kristian.ivarsson
2020-06-03 13:23 ` AF_UNIX/AF_LOCAL Corinna Vinschen
0 siblings, 1 reply; 3+ messages in thread
From: sten.kristian.ivarsson @ 2020-06-02 12:46 UTC (permalink / raw)
To: cygwin
Hey folks (probably Corinna more specifically)
As far as I know the "unix domain socket implementation" is not really
complete
We tried it and it didn't work for our purposes (the symptoms were UDP-like,
i.e. it seemed that some messages were lost along the way (or possibly ended
up in the wrong order)
As far as I understand, Microsoft/WinSock support AF_UNIX/AF_LOCAL with (at
least) SOCK_STREAM (I do not really know what system dependencies it
requires though and thus the Cygwin implementation might not utilize that at
all?)
The branch topic/af_unix seems to address this issue, so our question is if
anyone knows the status of the AF_UNIX/AF_LOCAL progress ?
We'd be glad to help out testing the topic/af_unix (if it is kind of freshly
rebased from the master-branch), but maybe it's just early work-in-progress
?
Best regards,
Kristian
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: AF_UNIX/AF_LOCAL
2020-06-02 12:46 AF_UNIX/AF_LOCAL sten.kristian.ivarsson
@ 2020-06-03 13:23 ` Corinna Vinschen
2020-06-11 6:37 ` Sv: AF_UNIX/AF_LOCAL sten.kristian.ivarsson
0 siblings, 1 reply; 3+ messages in thread
From: Corinna Vinschen @ 2020-06-03 13:23 UTC (permalink / raw)
To: cygwin
On Jun 2 14:46, Kristian Ivarsson via Cygwin wrote:
> Hey folks (probably Corinna more specifically)
>
> As far as I know the "unix domain socket implementation" is not really
> complete
>
> We tried it and it didn't work for our purposes (the symptoms were UDP-like,
> i.e. it seemed that some messages were lost along the way (or possibly ended
> up in the wrong order)
That shouldn't occur because the current AF_UNIX implementation is using
AF_INET sockets under the hood, and it doesn't implement any packet
caching overriding the OS buffers.
> As far as I understand, Microsoft/WinSock support AF_UNIX/AF_LOCAL with (at
> least) SOCK_STREAM (I do not really know what system dependencies it
> requires though and thus the Cygwin implementation might not utilize that at
> all?)
If we'd only support W10, that might be ok, but as long as we support
Vista/7/8/8.1, we need something else.
> The branch topic/af_unix seems to address this issue, so our question is if
> anyone knows the status of the AF_UNIX/AF_LOCAL progress ?
This is the new AF_UNIX implementation using pipes under the hood. I
started it quite some while ago but got thoroughly sidetracked and have
a lot other stuff on my plate.
The skeleton code is already in master. The topic branch is a bit
outdated and split from master so some merging is needed. It's built
into the Cygwin DLL with -D__WITH_AF_UNIX.
What this code needs is some dusting off and somebody picking it up
again. Maybe in winter I have some time for that again, but it wouldn't
hurt to have somebody else with interest in the new implementation to
help.
Patches welcome!
Also, nothing speaks against a third implementation using native Windows
AF_UNIX sockets under the hood on systems supporting them, provided the
pipe implementation works on older systems, too.
Corinna
--
Corinna Vinschen
Cygwin Maintainer
^ permalink raw reply [flat|nested] 3+ messages in thread
* Sv: AF_UNIX/AF_LOCAL
2020-06-03 13:23 ` AF_UNIX/AF_LOCAL Corinna Vinschen
@ 2020-06-11 6:37 ` sten.kristian.ivarsson
0 siblings, 0 replies; 3+ messages in thread
From: sten.kristian.ivarsson @ 2020-06-11 6:37 UTC (permalink / raw)
To: cygwin
> On Jun 2 14:46, Kristian Ivarsson via Cygwin wrote:
> > Hey folks (probably Corinna more specifically)
> >
> > As far as I know the "unix domain socket implementation" is not really
> > complete
> >
> > We tried it and it didn't work for our purposes (the symptoms were
> > UDP-like, i.e. it seemed that some messages were lost along the way
> > (or possibly ended up in the wrong order)
>
> That shouldn't occur because the current AF_UNIX implementation is using
> AF_INET sockets under the hood, and it doesn't implement any packet
> caching overriding the OS buffers.
Maybe the symptoms were explained bad. The real observable symptoms are that
the endpoint doesn't get a message once in a while and it, depending on
testcase, just "hangs" in a reading block though the other side successfully
sends them and in other testcases (where we have a sequence number in the
message) msg number X+1 ends up before X (etc) (which is ok with
DGRAM-semantics but not generally with AF_UNIX (as far as I understand))
Maybe the description of that messages are lost were bad, but maybe they are
dropped (perhaps by the fact that the socket-buffer or such is full (just a
wild guess))
If we get some spare time, we will try to reproduce this in a more simple
manner (i.e. a small test-program)
Keep up the good work,
Kristian
[snip]
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Maintainer
> --
> Problem reports: https://cygwin.com/problems.html
> FAQ: https://cygwin.com/faq/
> Documentation: https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-06-11 6:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-02 12:46 AF_UNIX/AF_LOCAL sten.kristian.ivarsson
2020-06-03 13:23 ` AF_UNIX/AF_LOCAL Corinna Vinschen
2020-06-11 6:37 ` Sv: AF_UNIX/AF_LOCAL sten.kristian.ivarsson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).