[libmicrohttpd] Sockets remain in CLOSE_WAIT state

[Santos Das]

Hi Christian,

Wishing you a happy new year!

We have set the MHD_OPTION_CONNECTION_TIMEOUT to 0 and we see that all the
connections remain in CLOSE_WAIT state.

We also have set the MHD_OPTION_CONNECTION_LIMIT to 1000 .

Any idea what could be wrong ?

Thanks, Santos

Re: [libmicrohttpd] Sockets remain in CLOSE_WAIT state

[Santos Das]

Hi Christian,

Please note I am using suspend-resume and not implementing
MHD_OPTION_NOTIFY_CONNECTION
to close . Not sure when the library closes the connection after it
receives FIN and move to CLOSE_WAIT.

Any pointers?

thanks, santos

On Fri, Jan 4, 2019 at 10:27 PM Santos Das  wrote:

> Hi Christian,
>
> Wishing you a happy new year!
>
> We have set the MHD_OPTION_CONNECTION_TIMEOUT to 0 and we see that all the
> connections remain in CLOSE_WAIT state.
>
> We also have set the MHD_OPTION_CONNECTION_LIMIT to 1000 .
>
> Any idea what could be wrong ?
>
> Thanks, Santos
>

Re: [libmicrohttpd] http2 suspend/resume

[Kunal Ekawde]

Hi Christian,

I could get multiple streams working with suspend/resume. Took the
following approach:

   1. When request is received, saved the stream id at application.
   2. Suspend now would suspend only the stream logically, so the
   connection is not suspended – no updating epoll fds as earlier, I update
   the stream as suspended. MHD_suspend_stream() – new API
   3. When the application wants to sends response (current example – after
   timer exp), it invokes an new API MHD_resume_stream. In here, I update the
   stream to be resumed and trigger the MDH inter thread communication.
   4. MHD invokes the callback so that response can be queued.
   5. On queuing the rsp and starting its internal epoll, I check for all
   the streams for that connections were suspended and have to be resumed, if
   so , update the epoll internal state and do epoll_ctl so that fd can be
   triggered to send the response.


Please let me know if this sounds logical or there is basic issue with this
approach.

Thanks,
Kunal

On Mon, Dec 31, 2018 at 2:18 PM Kunal Ekawde  wrote:

> Hi,
>
> I'm currently checking the http2 combo of nghttp2 + MHD provided by
> https://github.com/maru/libmicrohttpd-http2.
>
> It doesn't support multiple streams with suspend/resume. To try to make it
> work, I was thinking if following understanding is correct(only if version
> is http/2):
> To suspend, we need to suspend only the stream and resume also for a
> particular stream. Here, can we keep MHD connection still in non suspended
> state ? So something like create and add fd's to epoll for each stream and
> wake up when application triggers resume on the stream. Will the callbacks
> be affected and way response is queued ?
> Any pointers will be appreciated.
>
> Thanks,
> ~Kunal
>


-- 
~Kunal

Re: [libmicrohttpd] [Windows] Build fails on MinGW-w64 (0.9.62)

[Evgeny Grin]

Hi, It was fixed already in Git master by 1616caa17764c878bc18c6344a0f7f60b2cb596c -- Best Wishes,Evgeny Grin   28.12.2018, 09:08, "silvioprog" :Hello, I've tried to compile the latest stable version on MinGW-w64, but it raises the following error at build time (cut relevant parts only): wget --continue --content-disposition https://ftp.gnu.org/gnu/libmicrohttpd/libmicrohttpd-0.9.62.tar.gztar -zxvf libmicrohttpd-0.9.62.tar.gzcd libmicrohttpd-0.9.62/ && mkdir build && cd build/../configure --enable-static=yes --enable-shared=no --enable-messages=yes --enable-https=yes --enable-asserts=no --enable-coverage=no --disable-httpupgrade --disable-dauth --disable-doc --disable-examples --disable-curl ... configure: GNU libmicrohttpd 0.9.62 Configuration Summary:  Target directory:  /mingw32  Cross-compiling:   no  Operating System:  mingw32  Shutdown of listening socket trigger select: no  Inter-thread comm: socketpair  poll support:      yes  epoll support:     no  sendfile used:     no  HTTPS support:     yes (using libgnutls)  Threading lib:     w32  Use thread names:  no  Use debug asserts: no  Messages:          yes  Gettext:           yes  Basic auth.:       yes  Digest auth.:      no  HTTP "Upgrade":    no  Postproc:          yes  Build docs:        no  Build examples:    no  Test with libcurl: no, many unit tests will not run configure: HTTPS subsystem configuration:  License         :  LGPL only configure: WARNING: This will be a custom build with missing symbols. Do NOT use this build in a distribution. Building with these kinds of configure options is only for custom builds for embedded systems. Now the make: make ... ../../../src/microhttpd/daemon.c: In function 'thread_main_handle_connection':../../../src/microhttpd/daemon.c:1781:17: error: array type has incomplete element type 'struct pollfd'   struct pollfd p[1 + EXTRA_SLOTS];                 ^../../../src/microhttpd/daemon.c:1843:29: error: 'POLLIN' undeclared (first use in this function); did you mean 'POINT'?               p[0].events = POLLIN;                             ^~                             POINT../../../src/microhttpd/daemon.c:1843:29: note: each undeclared identifier is reported only once for each function it appears inIn file included from ../../../src/microhttpd/internal.h:72:0,                 from ../../../src/microhttpd/daemon.c:32:../../../src/microhttpd/mhd_sockets.h:340:27: warning: implicit declaration of function 'WSAPoll'; did you mean 'WSANtohl'? [-Wimplicit-function-declaration] #    define MHD_sys_poll_ WSAPoll                           ^../../../src/microhttpd/daemon.c:1846:23: note: in expansion of macro 'MHD_sys_poll_'               if (0 > MHD_sys_poll_ (p,                       ^../../../src/microhttpd/mhd_sockets.h:362:38: error: 'POLLRDBAND' undeclared (first use in this function); did you mean 'POLLIN'? #    define MHD_POLL_EVENTS_ERR_DISC POLLRDBAND                                      ^../../../src/microhttpd/daemon.c:2012:32: note: in expansion of macro 'MHD_POLL_EVENTS_ERR_DISC'        p[0].events |= POLLIN | MHD_POLL_EVENTS_ERR_DISC;                                ^~~~../../../src/microhttpd/daemon.c:2015:23: error: 'POLLOUT' undeclared (first use in this function); did you mean 'POLLIN'?        p[0].events |= POLLOUT | MHD_POLL_EVENTS_ERR_DISC;                       ^~~                       POLLIN../../../src/microhttpd/daemon.c:2055:39: error: 'POLLERR' undeclared (first use in this function); did you mean 'POLLOUT'?                (0 != (p[1].revents & (POLLERR | POLLHUP | POLLIN))) )                                       ^~~                                       POLLOUT../../../src/microhttpd/daemon.c:2055:49: error: 'POLLHUP' undeclared (first use in this function); did you mean 'POLLOUT'?                (0 != (p[1].revents & (POLLERR | POLLHUP | POLLIN))) )                                                 ^~~                                                 POLLOUTIn file included from ../../../src/microhttpd/daemon.c:44:0:../../../src/microhttpd/daemon.c: In function 'MHD_poll_all':../../../src/microhttpd/daemon.c:3736:30: error: invalid application of 'sizeof' to incomplete type 'struct pollfd'                      sizeof (struct pollfd));                              ^../../../src/microhttpd/mhd_compat.h:79:38: note: in definition of macro 'MHD_calloc_' #define MHD_calloc_(n,s) calloc((n),(s))                                      ^../../../src/microhttpd/daemon.c:3754:3: error: invalid use of undefined type 'struct pollfd'  p[poll_server].fd = ls;   ^../../../src/microhttpd/daemon.c:3754:3: error: dereferencing pointer to incomplete type 'struct pollfd'../../../src/microhttpd/daemon.c:3755:3: error: invalid use of undefined type 'struct pollfd'  p[poll_server].events = POLLIN;   ^../../../src/microhttpd/daemon.c:3755:26: error: 'POLLIN' undeclared (first use in this function); did you mean 'POINT'?  p[poll_server].events = POLLIN;                     

Re: [libmicrohttpd] [Windows] Build fails on MinGW-w64 (0.9.62)

[silvioprog]

Thanks for answering dude! :-)

I'm going to test it ... 🏃

On Fri, Jan 4, 2019 at 5:56 PM Evgeny Grin  wrote:

> Hi,
>
> It was fixed already in Git master by
> 1616caa17764c878bc18c6344a0f7f60b2cb596c
>
> --
> Best Wishes,
> Evgeny Grin
>
>  28.12.2018, 09:08, "silvioprog" :
>
> Hello,
>
> I've tried to compile the latest stable version on MinGW-w64, but it
> raises the following error at build time (cut relevant parts only):
>
> wget --continue --content-disposition
> https://ftp.gnu.org/gnu/libmicrohttpd/libmicrohttpd-0.9.62.tar.gz
> tar -zxvf libmicrohttpd-0.9.62.tar.gz
> cd libmicrohttpd-0.9.62/ && mkdir build && cd build/
> ../configure --enable-static=yes --enable-shared=no --enable-messages=yes
> --enable-https=yes --enable-asserts=no --enable-coverage=no
> --disable-httpupgrade --disable-dauth --disable-doc --disable-examples
> --disable-curl
>
> ...
>
> configure: GNU libmicrohttpd 0.9.62 Configuration Summary:
>   Target directory:  /mingw32
>   Cross-compiling:   no
>   Operating System:  mingw32
>   Shutdown of listening socket trigger select: no
>   Inter-thread comm: socketpair
>   poll support:  yes
>   epoll support: no
>   sendfile used: no
>   HTTPS support: yes (using libgnutls)
>   Threading lib: w32
>   Use thread names:  no
>   Use debug asserts: no
>   Messages:  yes
>   Gettext:   yes
>   Basic auth.:   yes
>   Digest auth.:  no
>   HTTP "Upgrade":no
>   Postproc:  yes
>   Build docs:no
>   Build examples:no
>   Test with libcurl: no, many unit tests will not run
>
> configure: HTTPS subsystem configuration:
>   License :  LGPL only
>
> configure: WARNING: This will be a custom build with missing symbols. Do
> NOT use this build in a distribution. Building with these kinds of
> configure options is only for custom builds for embedded systems.
>
> Now the make:
>
> make
>
> ...
>
> ../../../src/microhttpd/daemon.c: In function
> 'thread_main_handle_connection':
> ../../../src/microhttpd/daemon.c:1781:17: error: array type has incomplete
> element type 'struct pollfd'
>struct pollfd p[1 + EXTRA_SLOTS];
>  ^
> ../../../src/microhttpd/daemon.c:1843:29: error: 'POLLIN' undeclared
> (first use in this function); did you mean 'POINT'?
>p[0].events = POLLIN;
>  ^~
>  POINT
> ../../../src/microhttpd/daemon.c:1843:29: note: each undeclared identifier
> is reported only once for each function it appears in
> In file included from ../../../src/microhttpd/internal.h:72:0,
>  from ../../../src/microhttpd/daemon.c:32:
> ../../../src/microhttpd/mhd_sockets.h:340:27: warning: implicit
> declaration of function 'WSAPoll'; did you mean 'WSANtohl'?
> [-Wimplicit-function-declaration]
>  #define MHD_sys_poll_ WSAPoll
>^
> ../../../src/microhttpd/daemon.c:1846:23: note: in expansion of macro
> 'MHD_sys_poll_'
>if (0 > MHD_sys_poll_ (p,
>^
> ../../../src/microhttpd/mhd_sockets.h:362:38: error: 'POLLRDBAND'
> undeclared (first use in this function); did you mean 'POLLIN'?
>  #define MHD_POLL_EVENTS_ERR_DISC POLLRDBAND
>   ^
> ../../../src/microhttpd/daemon.c:2012:32: note: in expansion of macro
> 'MHD_POLL_EVENTS_ERR_DISC'
> p[0].events |= POLLIN | MHD_POLL_EVENTS_ERR_DISC;
> ^~~~
> ../../../src/microhttpd/daemon.c:2015:23: error: 'POLLOUT' undeclared
> (first use in this function); did you mean 'POLLIN'?
> p[0].events |= POLLOUT | MHD_POLL_EVENTS_ERR_DISC;
>^~~
>POLLIN
> ../../../src/microhttpd/daemon.c:2055:39: error: 'POLLERR' undeclared
> (first use in this function); did you mean 'POLLOUT'?
> (0 != (p[1].revents & (POLLERR | POLLHUP | POLLIN))) )
>^~~
>POLLOUT
> ../../../src/microhttpd/daemon.c:2055:49: error: 'POLLHUP' undeclared
> (first use in this function); did you mean 'POLLOUT'?
> (0 != (p[1].revents & (POLLERR | POLLHUP | POLLIN))) )
>  ^~~
>  POLLOUT
> In file included from ../../../src/microhttpd/daemon.c:44:0:
> ../../../src/microhttpd/daemon.c: In function 'MHD_poll_all':
> ../../../src/microhttpd/daemon.c:3736:30: error: invalid application of
> 'sizeof' to incomplete type 'struct pollfd'
>   sizeof (struct pollfd));
>   ^
> ../../../src/microhttpd/mhd_compat.h:79:38: note: in definition of macro
> 'MHD_calloc_'
>  #define MHD_calloc_(n,s) calloc((n),(s))
>   ^
> ../../../src/microhttpd/daemon.c:3754:3: error: invalid use of undefined
> type 'struct pollfd'
>   p[poll_

Re: [libmicrohttpd] Sockets remain in CLOSE_WAIT state

[Christian Grothoff]

Hi Santos,

CLOSE_WAIT is a TCP state in the kernel after a TCP connection is
finished. It typically lasts like 60--300s, depending on your kernel
configuration (you may want to read up on the TCP state machine).
You can change the time by changing
/proc/sys/net/ipv4/tcp_fin_timeout, but usually this is not an issue
(unless you have _way_ too many TCP connections from the same host, I've
only seen this matter on loopback, in which case usually enabling
keep-alive on the client-side helps).

Summary: this is not an issue in MHD, likely not one for anyone, just a
TCP artifact.

Happy hacking!

-Christian

On 1/4/19 6:29 PM, Santos Das wrote:
> Hi Christian,
> 
> Please note I am using suspend-resume and not
> implementing MHD_OPTION_NOTIFY_CONNECTION to close . Not sure when the
> library closes the connection after it receives FIN and move to CLOSE_WAIT.
> 
> Any pointers?
> 
> thanks, santos
> 
> On Fri, Jan 4, 2019 at 10:27 PM Santos Das  > wrote:
> 
> Hi Christian,
> 
> Wishing you a happy new year!
> 
> We have set the MHD_OPTION_CONNECTION_TIMEOUT to 0 and we see that
> all the connections remain in CLOSE_WAIT state. 
> 
> We also have set the MHD_OPTION_CONNECTION_LIMIT to 1000 .
> 
> Any idea what could be wrong ?
> 
> Thanks, Santos
> 



signature.asc
Description: OpenPGP digital signature

[libmicrohttpd] ZLib & MHD_create_response_from_fd_at_offset64: compression on demand

[silvioprog]

Hello dudes,

firstly, thanks Christian for indicating the MHD_fd* functions, I upgraded
my library to use them! :-)

Now I have a new challenge. I'm going to create two new examples for MHD
(issue #4914), however, I have a question. Is there any chance to use
zlib to compress data when creating a response via
MHD_create_response_from_fd_at_offset64()? I tried that, but it seems its
internal read() cannot  be intercepted (to compress data on demand using
zlib's compress2()). I would like to "intercept" the internal MHD's
file_reader() (response.c:572) to reuse it instead of rewriting a new one,
because the original already handles the reading in any supported platform.

Thanks in advance for any help!

--
Silvio Clécio

Re: [libmicrohttpd] Sockets remain in CLOSE_WAIT state

[Santos Das]

Hi Christian,

We see that it never times out, i.e remain in CLOSE_WAIT state forever.

Also, it is seen irrespective of whether we use loop back ip or a regular
eth0 IP.

>From my reading, I understand the following and we don't see that FIN is
received from Client but , we don't send FIN.
CLOSE_WAIT means that the local end of the connection has received a FIN
from the other end, but the OS is waiting for the program at the local end
to actually close its connection.



On Sat, Jan 5, 2019 at 4:36 AM Christian Grothoff 
wrote:

> Hi Santos,
>
> CLOSE_WAIT is a TCP state in the kernel after a TCP connection is
> finished. It typically lasts like 60--300s, depending on your kernel
> configuration (you may want to read up on the TCP state machine).
> You can change the time by changing
> /proc/sys/net/ipv4/tcp_fin_timeout, but usually this is not an issue
> (unless you have _way_ too many TCP connections from the same host, I've
> only seen this matter on loopback, in which case usually enabling
> keep-alive on the client-side helps).
>
> Summary: this is not an issue in MHD, likely not one for anyone, just a
> TCP artifact.
>
> Happy hacking!
>
> -Christian
>
> On 1/4/19 6:29 PM, Santos Das wrote:
> > Hi Christian,
> >
> > Please note I am using suspend-resume and not
> > implementing MHD_OPTION_NOTIFY_CONNECTION to close . Not sure when the
> > library closes the connection after it receives FIN and move to
> CLOSE_WAIT.
> >
> > Any pointers?
> >
> > thanks, santos
> >
> > On Fri, Jan 4, 2019 at 10:27 PM Santos Das  > > wrote:
> >
> > Hi Christian,
> >
> > Wishing you a happy new year!
> >
> > We have set the MHD_OPTION_CONNECTION_TIMEOUT to 0 and we see that
> > all the connections remain in CLOSE_WAIT state.
> >
> > We also have set the MHD_OPTION_CONNECTION_LIMIT to 1000 .
> >
> > Any idea what could be wrong ?
> >
> > Thanks, Santos
> >
>
>

Re: [libmicrohttpd] Sockets remain in CLOSE_WAIT state

[Santos Das]

Hi Christian,


We see that at the end of the load run, the connections at the TCP server
remain in CLOSE_WAIT state. We didn’t see this for single call. Also, I
wanted to tell you that all our connection are initiated from a single IP
as that is the load balancer IP and we are behind that.


We also observed that it  gets stuck in the CLOSE_WAIT state and remains
there forever , i.e Sockets are seen in this state even after the default
of TCP connection timeout.

>From all my study, it points out the TCP stack  will keep the connection in
CLOSE_WAIT state till the application call close on the socket.


Do we know when MHD call close normally ? Is there any instrumentation that
could tell us why /whether FIN is sent from the Server or NOT ?



https://access.redhat.com/solutions/437133


*CLOSE_WAIT - Indicates that the server has received the first FIN signal
from the client and the connection is in the process of being closed. This
means the socket is waiting for the application to execute **close()**. A
socket can be in CLOSE_WAIT state indefinitely until the application closes
it. Faulty scenarios would be like a file descriptor leak: server not
executing **close()** on sockets leading to pile up of CLOSE_WAIT sockets*


On Sat, Jan 5, 2019 at 10:04 AM Santos Das  wrote:

> Hi Christian,
>
> We see that it never times out, i.e remain in CLOSE_WAIT state forever.
>
> Also, it is seen irrespective of whether we use loop back ip or a regular
> eth0 IP.
>
> From my reading, I understand the following and we don't see that FIN is
> received from Client but , we don't send FIN.
> CLOSE_WAIT means that the local end of the connection has received a FIN
> from the other end, but the OS is waiting for the program at the local end
> to actually close its connection.
>
>
>
> On Sat, Jan 5, 2019 at 4:36 AM Christian Grothoff 
> wrote:
>
>> Hi Santos,
>>
>> CLOSE_WAIT is a TCP state in the kernel after a TCP connection is
>> finished. It typically lasts like 60--300s, depending on your kernel
>> configuration (you may want to read up on the TCP state machine).
>> You can change the time by changing
>> /proc/sys/net/ipv4/tcp_fin_timeout, but usually this is not an issue
>> (unless you have _way_ too many TCP connections from the same host, I've
>> only seen this matter on loopback, in which case usually enabling
>> keep-alive on the client-side helps).
>>
>> Summary: this is not an issue in MHD, likely not one for anyone, just a
>> TCP artifact.
>>
>> Happy hacking!
>>
>> -Christian
>>
>> On 1/4/19 6:29 PM, Santos Das wrote:
>> > Hi Christian,
>> >
>> > Please note I am using suspend-resume and not
>> > implementing MHD_OPTION_NOTIFY_CONNECTION to close . Not sure when the
>> > library closes the connection after it receives FIN and move to
>> CLOSE_WAIT.
>> >
>> > Any pointers?
>> >
>> > thanks, santos
>> >
>> > On Fri, Jan 4, 2019 at 10:27 PM Santos Das > > > wrote:
>> >
>> > Hi Christian,
>> >
>> > Wishing you a happy new year!
>> >
>> > We have set the MHD_OPTION_CONNECTION_TIMEOUT to 0 and we see that
>> > all the connections remain in CLOSE_WAIT state.
>> >
>> > We also have set the MHD_OPTION_CONNECTION_LIMIT to 1000 .
>> >
>> > Any idea what could be wrong ?
>> >
>> > Thanks, Santos
>> >
>>
>>

Re: [libmicrohttpd] Sockets remain in CLOSE_WAIT state

[Christian Grothoff]

Ah, sorry, I confused CLOSE_WAIT with TIME_WAIT. Hmm. You wrote that you
set the timeout to 0, which means "disable". Maybe that is the issue?

On 1/5/19 5:34 AM, Santos Das wrote:
> Hi Christian,
> 
> We see that it never times out, i.e remain in CLOSE_WAIT state forever.
> 
> Also, it is seen irrespective of whether we use loop back ip or a
> regular eth0 IP.
> 
> From my reading, I understand the following and we don't see that FIN is
> received from Client but , we don't send FIN.
> CLOSE_WAIT means that the local end of the connection has received a FIN
> from the other end, but the OS is waiting for the program at the local
> end to actually close its connection.  
> 
> 
> 
> On Sat, Jan 5, 2019 at 4:36 AM Christian Grothoff  > wrote:
> 
> Hi Santos,
> 
> CLOSE_WAIT is a TCP state in the kernel after a TCP connection is
> finished. It typically lasts like 60--300s, depending on your kernel
> configuration (you may want to read up on the TCP state machine).
> You can change the time by changing
> /proc/sys/net/ipv4/tcp_fin_timeout, but usually this is not an issue
> (unless you have _way_ too many TCP connections from the same host, I've
> only seen this matter on loopback, in which case usually enabling
> keep-alive on the client-side helps).
> 
> Summary: this is not an issue in MHD, likely not one for anyone, just a
> TCP artifact.
> 
> Happy hacking!
> 
> -Christian
> 
> On 1/4/19 6:29 PM, Santos Das wrote:
> > Hi Christian,
> >
> > Please note I am using suspend-resume and not
> > implementing MHD_OPTION_NOTIFY_CONNECTION to close . Not sure when the
> > library closes the connection after it receives FIN and move to
> CLOSE_WAIT.
> >
> > Any pointers?
> >
> > thanks, santos
> >
> > On Fri, Jan 4, 2019 at 10:27 PM Santos Das  
> > >> wrote:
> >
> >     Hi Christian,
> >
> >     Wishing you a happy new year!
> >
> >     We have set the MHD_OPTION_CONNECTION_TIMEOUT to 0 and we see that
> >     all the connections remain in CLOSE_WAIT state. 
> >
> >     We also have set the MHD_OPTION_CONNECTION_LIMIT to 1000 .
> >
> >     Any idea what could be wrong ?
> >
> >     Thanks, Santos
> >
> 



signature.asc
Description: OpenPGP digital signature

Re: [libmicrohttpd] Sockets remain in CLOSE_WAIT state

[Christian Grothoff]

On 1/5/19 5:51 AM, Santos Das wrote:
> Hi Christian,
>  
> 
> We see that at the end of the load run, the connections at the TCP
> server remain in CLOSE_WAIT state. We didn’t see this for single call.
> Also, I wanted to tell you that all our connection are initiated from a
> single IP as that is the load balancer IP and we are behind that.

The single IP should hardly matter.

> We also observed that it  gets stuck in the CLOSE_WAIT state and remains
> there forever , i.e Sockets are seen in this state even after the
> default of TCP connection timeout.

What kind of method do you use to generate the response?

> From all my study, it points out the TCP stack  will keep the connection
> in CLOSE_WAIT state till the application call close on the socket.  

Right, so the question now is why the socket is not closed. Two
reasons are clearly coming together: (1) you disabled the timeout,
(2) for some reason MHD believes the response is not done. So we
should also figure out why your response is not considered "finished" by
MHD.

> Do we know when MHD call close normally ? Is there any instrumentation
> that could tell us why /whether FIN is sent from the Server or NOT ? 

You could just 'strace' and look for the close() call, but that won't
tell you where exactly the issue is.



signature.asc
Description: OpenPGP digital signature