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@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@mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/pdns-users
_______________________________________________
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users
