Because the fromadress was already known. It's always the server.
At least one of us has a misunderstanding here, because I understood it as if he is currently writing the server, and the server probably needs to use recvfrom to identify the client
Besides that... If my code also generates a 10022 error there is something else wrong and it has nothing to do with recvfrom. If it works we can expand it with recvfrom if needed
I could reproduce this error on my machine, and as I already stated, the problem with stack pointers for the memory is something that is known for the winapi for quite some time (and took me a many hours to find out when I first encountered it).
But with this code it works on my machine:
uses
sockets;
const
UDPPackLen = 512;
var
sock: Tsocket;
buff: String;
ServerAddr: sockaddr_in;
FromAddr: psockaddr_in;
FromAddrLen: PInteger;
ClientAddr: String;
ClientPort: Word;
MessageSize: SizeInt;
begin
// Start UDP Server
sock := fpsocket(AF_INET, SOCK_DGRAM, 0);
ServerAddr.sin_family:= AF_INET;
ServerAddr.sin_addr := StrToNetAddr('127.0.0.1'); // server IP
ServerAddr.sin_port := 531; // server port
fpbind(sock, @ServerAddr, SizeOf(ServerAddr));
// Receive Data
SetLength(buff, UDPPackLen);
new(FromAddr);
new(FromAddrLen);
try
FromAddrLen^ := SizeOf(FromAddr^);
MessageSize := fprecvfrom(sock, @buff[1], Length(buff), 0, psockaddr(FromAddr), FromAddrLen);
WriteLn('err: ', socketerror);
SetLength(buff, MessageSize);
ClientAddr := NetAddrToStr(FromAddr^.sin_addr);
ClientPort := NToHs(FromAddr^.sin_port);
finally
Dispose(FromAddr);
Dispose(FromAddrLen);
end;
WriteLn(buff);
ReadLn;
end.
Of course the IP needs to be changed (I don't have IP 1.1.1.2)
PS: @TE are you shure you have IP 1.1.1.2, because as far as I know the 1.1.1.x IP range is owned by Cloudflare, who host their infrastructure their (as low ip numbers are a few nanoseconds faster than high ones in switching, to give them more performance for their CDN services)