public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* 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).