All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: "Lili Püspök" <poordirtylili@gmail.com>
Cc: linux-man@vger.kernel.org, Heinrich Schuchardt <xypron.glpk@gmx.de>
Subject: Re: patch - fixing sample program in unix.7
Date: Sat, 16 Mar 2024 01:12:33 +0100	[thread overview]
Message-ID: <ZfTj8d0bNFhocFI5@debian> (raw)
In-Reply-To: <CALPhBBa47G3H18HeKasT-X6WndOy-1O2n4yR0D-vZALrLzLeQQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 8047 bytes --]

Hi Lili,

On Wed, Mar 06, 2024 at 09:02:47PM +0100, Lili Püspök wrote:
> Hi Alex, I tried to follow your instructions and applied your concept.
> I hope it is ok now.

It is.

> Cheers
> PuLi
> 
> 
> From fca55af92ec1993823e70a4460a08197fa8da01a Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?P=C3=BCsp=C3=B6k=20Lili?= <poordirtylili@gmail.com>
> Date: Wed, 6 Mar 2024 20:51:38 +0100
> Subject: [PATCH] [patch] sample program in man7/unix.7
> 
> Signed-off-by: PuLi <poordirtylili@gmail.com>
> Fixes: 15545eb6d7ae ("unix.7: Add example")
> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
> 
> Client wants to send END while server already closed the connection
> on DOWN, so connection is broken instead of the Result = 0 in the
> sample on sending a single DOWN.
> Now, the server disconnects only on first END. After DOWN, all further
> processing of number stops.
> Patch does not handle cases of double END sending, multiple clients
> etc.

Patch applied.  Thanks.
<https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib&id=4fe1c74b42f99b3682114e1dab1200f6ced6881f>

Have a lovely night!
Alex

> ---
>  man7/unix.7 | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/man7/unix.7 b/man7/unix.7
> index cb1dcae45..2dc4f489e 100644
> --- a/man7/unix.7
> +++ b/man7/unix.7
> @@ -1057,12 +1057,16 @@ main(int argc, char *argv[])
>  \&
>              if (!strncmp(buffer, "DOWN", sizeof(buffer))) {
>                  down_flag = 1;
> -                break;
> +                continue;
>              }
>  \&
>              if (!strncmp(buffer, "END", sizeof(buffer))) {
>                  break;
>              }
> +\&
> +            if (down_flag) {
> +                continue;
> +            }
>  \&
>              /* Add received summand. */
>  \&
> -- 
> 2.39.2
> 
> Alejandro Colomar <alx@kernel.org> ezt írta (időpont: 2024. márc. 6.,
> Sze, 13:19):
> >
> > [CC += Heinrich]
> >
> > Hi Lili,
> >
> > On Mon, Mar 04, 2024 at 05:41:17PM +0100, Lili Püspök wrote:
> > > Hi Alejandro,
> > > Thanks for replying.
> > >
> > > The client, after connecting, processes the argv items and sends all
> > > of them, then issues the sending of a final END which, on the server
> > > side, is not expected after DOWN which would halt the reading (In that
> > > case, too, the processing of argv + the END should happen).
> > > After the change,  DOWN does not break the reading, the closing END is
> > > processed and there is no broken connection when client tries to send
> > > END while the server closes after sending the result, which is not
> > > received by the client.
> >
> > Hmmm, now I understand.
> >
> > >
> > > --- without DOWN ----
> > > client         server
> > > argv1..N + END --->
> > > <----- result
> > > <---- connection closed
> > >
> > > -----------problem-----------
> > > argv1...N + DOWN ->
> > > <---- result
> > > END -> ?????
> > > <---- connection closed
> > >
> > > ------- solution:---------
> > > argv1...N + DOWN + END ->
> > > <---- result
> > > <---- connection closed
> >
> > Yep, I can reproduce this problem all the way back to the original
> > implementation of the example programs.  I extracted the original
> > programs with:
> >
> >         $ git show 15545eb6d7:man7/unix.7 | man /dev/stdin | cat
> >
> > And then cut and paste to the C files.
> >
> >         $ cc -Wall -o server server.c
> >         $ cc -Wall -o client client.c
> >         $ ./server &
> >         [1] 94644
> >         $ ./client 3 4
> >         Result = 7
> >         $ ./client 11 -5
> >         Result = 6
> >         $ ./client DOWN
> >         recv: Connection reset by peer
> >         [1]+  Done                    ./server
> >         $
> >
> > This behavior conflicts with the behavior shown in the manual page,
> > which shows (for the last command):
> >
> >         $ ./client DOWN
> >         Result = 0
> >         [1]+  Done                    ./server
> >
> > So it seems like a bug.  Maybe the server program was slow enough when
> > it was implemented in 2016, that the server hadn't closed the socket
> > when the client sent "END", so the client didn't fail to read the
> > result??
> >
> > Anyway, we need to fix it.  Agree.
> >
> > Please add
> >
> >         Fixes: 15545eb6d7ae ("unix.7: Add example")
> >         Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >
> > to the commit message, as well as a small description of the problem.
> >
> > > I hope I did not overlook something.
> >
> > However, I'm not convinced by your patch.  It seems to allow
> >
> >         $ ./client DOWN 4 3
> >
> > which I don't think we want to support.  I think we have two options:
> >
> > -  The client avoids sending "END" after "DOWN" (so DOWN implies END).
> > -  The server only accepts "END" after "DOWN".
> >
> > Does it make sense to you?
> >
> > Have a lovely day!
> > Alex
> >
> > > OK, maybe with a unique message containing only the DOWN from client,
> > > the issue is not visible, because there is no result to return to
> > > client and we don't care it the connection is just broken....
> > >
> > > Cheers
> > > PuLi
> > >
> > > Alejandro Colomar <alx@kernel.org> ezt írta (időpont: 2024. márc. 4., H, 17:22):
> > > >
> > > > Hi Lili,
> > > >
> > > > > Subject: Re: patch - fixing sample program in unix.7
> > > >
> > > > On Sun, Mar 03, 2024 at 08:27:17PM +0100, Lili Püspök wrote:
> > > > > diff --git a/man7/unix.7 b/man7/unix.7
> > > >
> > > > Please add some commit message.  I don't understand what this patch
> > > > does.  How is it broken, and how does it fix it?
> > > >
> > > > > index cb1dcae45..7fb41af99 100644
> > > > > --- a/man7/unix.7
> > > > > +++ b/man7/unix.7
> > > > > @@ -1057,7 +1057,7 @@ main(int argc, char *argv[])
> > > > > \&
> > > > >             if (!strncmp(buffer, "DOWN", sizeof(buffer))) {
> > > > >                 down_flag = 1;
> > > > > -                break;
> > > > > +                continue;
> > > >
> > > > DOWN is used to stop the server.  How would 'continue' help?
> > > >
> > > >
> > > >         $ MANWIDTH=66 man unix | grep -C2 DOWN
> > > >              tegers.  The client prints the sum and exits.   The  server
> > > >              waits  for the next client to connect.  To stop the server,
> > > >              the client is called with the command‐line argument "DOWN".
> > > >
> > > >              The following output was recorded while running the  server
> > > >              in the background and repeatedly executing the client.  Ex‐
> > > >              ecution  of  the  server  program ends when it receives the
> > > >              "DOWN" command.
> > > >
> > > >            Example output
> > > >         --
> > > >                  $ ./client 11 -5
> > > >                  Result = 6
> > > >                  $ ./client DOWN
> > > >                  Result = 0
> > > >                  [1]+  Done                    ./server
> > > >         --
> > > >                          /* Handle commands. */
> > > >
> > > >                          if (!strncmp(buffer, "DOWN", sizeof(buffer))) {
> > > >                              down_flag = 1;
> > > >                              break;
> > > >         --
> > > >                      close(data_socket);
> > > >
> > > >                      /* Quit on DOWN command. */
> > > >
> > > >                      if (down_flag) {
> > > >
> > > > Have a lovely day,
> > > > Alex
> > > >
> > > >
> > > > >             }
> > > > > \&
> > > > >             if (!strncmp(buffer, "END", sizeof(buffer))) {
> > > > >
> > > >
> > > > --
> > > > <https://www.alejandro-colomar.es/>
> > > > Looking for a remote C programming job at the moment.
> >
> > --
> > <https://www.alejandro-colomar.es/>
> > Looking for a remote C programming job at the moment.

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2024-03-16  0:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-03 19:27 patch - fixing sample program in unix.7 Lili Püspök
2024-03-04 16:21 ` Alejandro Colomar
2024-03-04 16:41   ` Lili Püspök
2024-03-06 12:19     ` Alejandro Colomar
2024-03-06 20:02       ` Lili Püspök
2024-03-16  0:12         ` Alejandro Colomar [this message]

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=ZfTj8d0bNFhocFI5@debian \
    --to=alx@kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=poordirtylili@gmail.com \
    --cc=xypron.glpk@gmx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.