[Pdns-users] [EXT] Re: remote backend

[Alexis Fidalgo]

Check this, i removed the code from my responder by now but it was something like this

func main() {
    l, err := net.ListenUnix("unix", &UnixAddr{Name: "unix",Net :"/tmp/echo.sock",})
    if err != nil {
        panic(err)
    }

    for {
        fd, err := l.Accept()
        if err != nil {
            panic(err)
        }

    go func(fd net.Conn) {  
        var buf [1024]byte
        n, err := fd.Read(buf)
        if err!=nil{
            panic(err)
        }
        data := buf[0:netip]
        println("Server got:", string(data))
        _, err = c.Write(data)
        if err != nil {
            panic(err)
        }
    }(fd)}
}

Using this (tested with pdns as client, a python cliend pasted below, a golang client and also netcat) causes

1. i can connect
2. i can send a message and it’s printed
3. answer is received
4. complete lock, im not able to send any other message (yes, starting a different instance of any client sends another message and locks and so on)

If i add (right before }(fd)} (inside the for loop) an “fd.Close()” what happens is, there’s no lock anymore, i can send messages over and over again, but (the famous but) doesn’t matter which client i use (python, pdns, golang, java) i need to start the client everytime.

Example

import socket
import sys
import time
import json

with socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM) as client:
    client.connect("/tmp/pra.sock")

    while True:
        client.send(json.dumps({'method':'initialize'}).encode('utf-8'))
        v = client.recv(1024)
        print(f"--> {v}")
        time.sleep(1)

    client.close()

Scenario 1 (without the fd.Close())
Starting this, only sends and receive first message and locks

Scenario 2 (with fd.Close())
Starting this, sends and receives first message and throws an Exception because Broken Pipe

You can see im moving the read/answer to a different coroutine on every call to avoid blocking the socket in anyway but it doesnt help.

Note:
Using SOCKET_DGRAM i was able to loop for ever with no problem, i tried to set that in unixconnector.cc <http://unixconnector.cc/> changing the socket type but is not that simple.

Note 2:
Helped a lot what you told me, i wrote a simple python script to stress the responder (putting pdns aside, only pcap’d real traffic to have real queries for my script) and i found something interesting, as more threads i open pushing the responder, there’s queries that takes more and more time to be answered, a good reason for the http connection between pdns > backend fails with timeout and DNS client see no responses. im working on that right now. nevertheless i would like to have the option of unixsockets if possible for different small scenarios (example, a single pod containing pdns+backend+redis+mongo) able to be replicated a few times in a small K8 cluster.

Hope it helps





> On 30 Nov 2023, at 05:18, Remi Gacogne via Pdns-users <pdns-users at mailman.powerdns.com> wrote:
> 
> On 29/11/2023 01:07, Alexis Fidalgo wrote:
>> Problem is (and i’ve testing with golang and python) after the answer the “initialize” message, the socket is closed, so, getAllDomains message is being sent using a closed socket and that’s why i don’t see it on the responder side and pdns does not receive and answer, polls 2 times and reaches timeout.
> 
> Why do you think the socket is closed? It doesn't show up in your previous strace log, and poll() wouldn't not time out but immediately return an error if the socket had been closed.
> 
>> i can see there’s no test for unixsocket in the source tree.
> 
> There is such a test in test-remotebackend-unix.cc
> 
> -- 
> Remi Gacogne
> PowerDNS.COM BV - https://www.powerdns.com/
> 
> _______________________________________________
> Pdns-users mailing list
> Pdns-users at mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/pdns-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20231130/cd952309/attachment-0001.htm>