On Sun, 27 Sep 2020, Noel Duffy via fpc-pascal wrote:
On 26/09/20 9:07 pm, Michael Van Canneyt via fpc-pascal wrote:
On Sat, 26 Sep 2020, Noel Duffy via fpc-pascal wrote:
To restate the question, is 64k too much overhead for DNS queries? That
overhead would be present on all queries, regardless of whether UDP or TCP
was used.
I would then prefer to allocate a dynamic buffer. A simple "Array of Byte"
can
easily be managed with SetLength() and it is automatically disposed of when
not needed.
An unintended consequence of attempting to replace the TPayLoad static array
with a dynamic one is that the TQueryData record can no longer be passed to
fpSendTo as a stream of octets by passing a pointer to it.
I.e,
Function Query(Resolver : Integer; Var Qry,Ans : TQueryData; QryLen :
Integer;
Var AnsLen : Integer) : Boolean;
begin
[...]
fpsendto(sock,@qry,qrylen+12,0,@SA,SizeOf(SA));
When TPayLoad is made dynamic, the final member of TQueryData changes from an
array of octets to a pointer. Now passing a pointer to Qry results in the
pointer to the dynamic array being serialized instead of the query payload.
Naturally the DNS server will turn up its nose at that and return a
sternly-worded error code in protest.
The payload data will have to be manually serialized to octets, I think. At
least I don't know of any way to serialize a record that contains pointers
using any feature of the language or api in the RTL. Doing manual
serialization will also require more memory, of course. The quantities aren't
huge, though, so I don't think it matters hugely. But more experienced FPC
developers may be able to recommend a better way, of course!
Hm. I don't think this is a good way then. Seems like a little too much
overhead: allocating a buffer for TPayload, and then allocating a second one
for sending everything in 1 block to the server. This will impact speed
significantly.
Probably it is then better to go for 2 kinds of records, one for UPD, one
for TCP ?
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
