From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-developers@cygwin.com
Subject: Re: Problems with the (new) implementation of AF_UNIX datagram sockets
Date: Fri, 16 Apr 2021 11:37:56 +0200 [thread overview]
Message-ID: <YHla9Oaj7UTEPnOA@calimero.vinschen.de> (raw)
In-Reply-To: <9db1d7ab-fe47-6f8c-db65-c9fe5e18952b@maxrnd.com>
On Apr 15 16:50, Mark Geisert wrote:
> Ken Brown wrote:
> > On 4/15/2021 9:58 AM, Corinna Vinschen wrote:
> > > On Apr 15 09:16, Ken Brown wrote:
> > > > On 4/15/2021 7:49 AM, Corinna Vinschen wrote:
> > > > [...]
> > > > > Another idea might be to implement send/recv on a DGRAM socket a bit
> > > > > like accept. Rather than creating a single_instance socket, we create a
> > > > > max_instance socket as for STREAM socket listeners. The server side
> > > > > accepts the connection at recv and immediately opens another pipe
> > > > > instance, so we always have at least one dangling instance for the next
> > > > > peer.
> > > >
> > > > I thought about that, but you would still have the problem (as in 1 above)
> > > > that the pipe instance isn't available until recv is called.
> > >
> > > There always is at least one instance. Do you mean, two clients are
> > > trying to send while the server is idly playing with his toes?
> >
> > Yes. That was essentially the situation in the test case attached to
> >
> > https://cygwin.com/pipermail/cygwin/2021-April/248210.html
> >
> > It was actually one client sending many messages while the server was
> > playing with his toes, but the effect was the same.
>
> Sending datagrams between processes on the same system could be thought of
> as similar to sending/receiving messages on a POSIX message queue. Though
> the mq_* man pages make it seem like mqs are intended for within-process
> messaging. But if a datagram receiver created a message queue that datagram
> senders could open, couldn't that provide buffering and allow multiple
> clients? Kindly ignore if insane.
Interesting idea, actually. Message queues already implement a lot of
what a unix socket needs in terms of sending/receiving data. The pipe
would only be needed for credential and descriptor passing, ultimately :)
Corinna
next prev parent reply other threads:[~2021-04-16 9:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-14 16:15 Ken Brown
2021-04-15 11:49 ` Corinna Vinschen
2021-04-15 13:16 ` Ken Brown
2021-04-15 13:58 ` Corinna Vinschen
2021-04-15 14:53 ` Ken Brown
2021-04-15 23:50 ` Mark Geisert
2021-04-16 9:37 ` Corinna Vinschen [this message]
2021-04-17 2:54 ` Mark Geisert
2021-04-17 16:05 ` Ken Brown
2021-04-19 8:48 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YHla9Oaj7UTEPnOA@calimero.vinschen.de \
--to=corinna-cygwin@cygwin.com \
--cc=cygwin-developers@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).