Reputation: 107
I'm writing a small application which includes UDP Hole-Punching for P2P-Communication implemented in Linux (Posix Sockets). It works well so far but I do have a problem with the incoming packets.
After the two clients received the peerinformation of the respective client they start sending UDP-Packets to make holes in their firewall.
And here my problem pops in: After sending the "HolePunching-Packet" the client listens (rcv) for incoming packets. If the client receives a "HolePunching-Packet", the Punching process is beeing stopped successfully and the user can start receiving/sending userdata.
But if the HolePunching-Packet of the other client is beeing held by the clients firewall, this packet will never reach the rcv-call and the current thread will be blocked until the next userdata "wakes up" the client, but this perticular packet is being consumed by the Punching-process and can't be relayed to the user.
So I'm searching for any method to put back the first received udp-packet back into the receive-buffer of the system. I can't use my own (char) buffers as a project contraint and have to find a workaround if there is no way to achieve this using posix-methods.
Do you guys know any method to do this in Posix systems?
Here is a rough schema of how my application works:
SocketClass
{
Punching
{
send(Give me the IP:PORT of Client2)
recv(Peerinformation)
send(HolePunchingPacket to client2)
recv(HolePunchingPacket from client2 or userdata)
if (recvedPacket != HolePunching-Packet)
put_back_in_recvbuffer(recvedPacket)
done
}
UserCode
{
[...]
}
}
Upvotes: 0
Views: 268
Reputation: 84169
You can use MSG_PEEK
flag with recv(2)
in you "punching" process, and then only de-queue data when needed, but honestly, this looks like a kludge. Why not implement a clean state machine for your process and forward packets to appropriate code paths according to the state?
Upvotes: 2