Easiest way to send UDP packets

[TRon]

You example gives error:

Thank you very much for testing and the feedback dseligo.

That is strange... according to the fpc documentation it should retrieve the length.

fpRecvFrom receives data in buffer Buf with maximum length Len from socket S. Receipt is controlled by options in Flags. The location pointed to by from will be filled with the address from the sender, and it's length will be stored in fromlen. The function returns the number of bytes received, or -1 on error. AddrLen.

So, it is/was my understanding I did not have to set slen ... but perhaps my interpretation of the bold underlined text is wrong ?

edit:
Indeed according to man:

The argument addrlen is a value-result argument, which the caller should initialize before the call to the size of the buffer associated with src_addr, and modified on return to indicate the actual size of the source address.

So, I stand corrected. And also a good point to show that checking results is important  (though strangely the original code worked without errors for me on linux 64 bit)

[ChrisTG]

A small update from my side: I was able to succefully generate and send the WOL-packet using Warfley's neat unit.
Here's my updated code:

Code: Pascal  [Select][+][-]

1. program udp_send;
2.  
3. {$mode objfpc}{$H+}
4.  
5. uses SimpleSockets, sysutils, strutils;
6.  
7. var
8.   Sock: TSocket;
9.   HostIP: PChar = '192.168.1.255';
10.   HostPort: Word = 7;
11.   AString: String = chr(255) + chr(255) + chr(255) + chr(255) + chr(255) + chr(255);
12.   MAC: String = '112233445566';
13.   MACchr: String;
14.   i: Integer;
15.  
16. begin
17.   i := 1;
18.   MACchr := '';
19.   while i < Length(MAC) do
20.   begin
21.     MACchr := MACchr + chr(StrToInt('$'+MAC[i]+MAC[i+1]));
22.     i := i + 2;
23.   end;
24.  
25.   MACchr := DupeString(MACchr, 16);
26.   AString := AString + MACchr;
27.  
28.   Sock := UDPSocket(stIPv4);
29.   try
30.     SendStrTo(Sock, IN4Address(HostIP), HostPort, AString);
31.   finally
32.     CloseSocket(Sock);
33.   end;
34.  
35. end.            
36.  

Two points are interesting here:
1) Somehow no socketopts are needed for sending broadcast-packets, even though there is no code to setting this in Warfley's unit.
2) My native approach using the "Sockets"-unit did not work, but this wrapper-unit does. So there must be some magic in Warfley's code somewhere. I think I'll dig through it to understand the mistake(s) in my former tries.

Anyway, thank you all for your input here, especially Warfley for creating this useful unit.

[MarkMLl]

1) Somehow no socketopts are needed for sending broadcast-packets, even though there is no code to setting this in Warfley's unit.

From memory, I don't think Windows is as strict at rejecting this sort of thing.

However even the unix approach is, by now, missing an important point: for at least the last 20 years it has been relatively easy for a computer's privileged user to get it connected directly to the Internet, i.e. without one or more NAT layers. To assume that every one of those billion or so users is a "responsible netizen" is unrealistic, and sooner or later we are going to see fundamental protocol changes to accommodate that. It is unlikely that those changes will leave network programming anything like as easy as it has been for the last 40+ years.

2) My native approach using the "Sockets"-unit did not work, but this wrapper-unit does. So there must be some magic in Warfley's code somewhere. I think I'll dig through it to understand the mistake(s) in my former tries.

If I had a Windows- and preferably a WoL target- system conveniently to hand I'd take a look at that.

MarkMLl