在 Delphi 7 中运行的 ZeroConf/Bonjour 代码在 2009 年不起作用
我对 DNSServiceRegister 有以下声明:
function DNSServiceRegister
(
var sdRef: TDNSServiceRef;
const flags: TDNSServiceFlags;
const interfaceIndex: uint32_t;
const name: PUTF8String; //* may be NULL */
const regType: PUTF8String;
const domain: PUTF8String; //* may be NULL */
const host: PUTF8String; //* may be NULL */
const port: uint16_t;
const txtLen: uint16_t;
const txtRecord: Pointer; //* may be NULL */
const callBack: TDNSServiceRegisterReply; //* may be NULL */
const context: Pointer //* may be NULL */
): TDNSServiceErrorType; stdcall; external DNSSD_DLL;
在我的 Bonjour 框架中,我对已宣布的服务处于活动状态(即通过 Bonjour 实际开始宣布自身)有以下响应:
procedure TAnnouncedService.Activate;
var
flags: Cardinal;
name: UTF8String;
svc: UTF8String;
pn: PUTF8String;
ps: PUTF8String;
begin
fPreAnnouncedServiceName := ServiceName;
inherited;
if AutoRename then
flags := 0
else
flags := kDNSServiceFlagsNoAutoRename; { - do not auto-rename }
if (ServiceName <> '') then
begin
name := ServiceName;
pn := PUTF8String(name);
end
else
pn := NIL;
svc := ServiceType;
ps := PUTF8String(svc);
CheckAPIResult(DNSServiceRegister(fHandle,
flags,
0 { interfaceID - register on all interfaces },
pn,
ps,
NIL { domain - register in all available },
NIL { hostname - use default },
ReverseBytes(Port),
0 { txtLen },
NIL { txtRecord },
DNSServiceRegisterReply,
self));
TBonjourEventHandler.Create(fHandle);
end;
当然,这比我认为严格需要的更详细它在 Delphi 7 中以更简洁的形式运行得非常好。我将许多操作扩展为显式步骤以方便调试,例如能够识别 Delphi 2009 中“幕后”可能发生的字符串有效负载的任何隐式转换。
即使在这种不整洁的扩展形式中,该代码也可以编译和运行在 Delphi 7 中运行得很好,但如果我用 Delphi 2009 编译并运行,我不会收到任何关于我的服务的公告。
例如,如果我将此代码作为 Delphi 7 应用程序的一部分运行以注册 _daap._tcp
服务(iTunes 共享库),我会看到它在 iTunes 的运行实例中弹出。如果我在 Delphi 2009 中不加修改地重新编译完全相同的应用程序并运行它,我不会看到我的服务出现在 iTunes 中。
使用 dns-sd 命令行实用程序进行监控时,我得到了相同的行为。也就是说,用 Delphi 7 编译的服务代码的行为正如我所期望的,在 Delphi 2009 中编译的 - 什么也没有。
我没有从 Bonjour API 收到任何错误 - 正在调用 DNSServiceRegisterReply 回调,错误代码为 0(零),即成功,如果我提供一个 NIL 名称参数并在标志中指定 AutoRename,那么我的服务就会被分配正确的默认名称。但该服务仍然没有出现在 iTunes 中。
我不知道发生了什么。
正如您可能从代码的扩展中看出的那样,我一直在寻找 Delphi 2009 中的 Unicode 实现引入的潜在错误,但这似乎没有任何结果。
该代码最初是针对 Bonjour API/SDK 版本 1.0.3 开发的。我已经更新到 1.0.6 以防万一,但没有成功。 afaict 1.0.6 只是添加了一个用于获取“属性”的新功能,目前仅支持“DaemonVersion”属性来获取 Bonjour 版本 - 这工作得很好。
注意:我知道现在的代码在 Delphi 7 中在技术上并不是 UTF8 安全的 - 我已经尽可能消除了显式转换,以便使 Delphi 2009 应用的自动转换尽可能简单。我现在的目标是在 Delphi 2009 中实现此功能,然后从该解决方案向后工作,希望找到与早期版本的 Delphi 兼容的方法。
另请注意: 我最初也遇到了浏览问题用于广告服务,即识别网络上实际的 iTunes 共享库。这些问题是由 Delphi 2009 中的 Unicode 处理引起的,并且已得到解决。我的 Delphi 2009 代码同样能够识别实际的 iTunes 共享库并查询它的 TXT 记录。只是这个服务注册不起作用。
我一定错过了一些愚蠢而明显的事情。
有人有什么想法吗?
更新
回到这个问题后,我现在发现了以下内容:
如果我打开了 D2009 之前的版本和 D2009+ IDE(例如 D2006 和 D2010),并加载了相同项目同时进入两个 IDE:
- 在 2006 下构建并运行:它可以工作 - iTunes 获取了我的服务公告
- 切换到 D2010 并运行(无需构建):它进行了最少的编译、运行和工作。
在 D2010 中执行完整构建:它停止工作
切换回 D2006 并运行(不构建):它不起作用
- 在 D2006 中进行完整构建:它再次起作用
这会给任何人任何其他想法吗?
I have the following declaration for DNSServiceRegister:
function DNSServiceRegister
(
var sdRef: TDNSServiceRef;
const flags: TDNSServiceFlags;
const interfaceIndex: uint32_t;
const name: PUTF8String; //* may be NULL */
const regType: PUTF8String;
const domain: PUTF8String; //* may be NULL */
const host: PUTF8String; //* may be NULL */
const port: uint16_t;
const txtLen: uint16_t;
const txtRecord: Pointer; //* may be NULL */
const callBack: TDNSServiceRegisterReply; //* may be NULL */
const context: Pointer //* may be NULL */
): TDNSServiceErrorType; stdcall; external DNSSD_DLL;
In my Bonjour framework I have the following response to an announced service being made active (i.e. to actually start announcing itself, via Bonjour):
procedure TAnnouncedService.Activate;
var
flags: Cardinal;
name: UTF8String;
svc: UTF8String;
pn: PUTF8String;
ps: PUTF8String;
begin
fPreAnnouncedServiceName := ServiceName;
inherited;
if AutoRename then
flags := 0
else
flags := kDNSServiceFlagsNoAutoRename; { - do not auto-rename }
if (ServiceName <> '') then
begin
name := ServiceName;
pn := PUTF8String(name);
end
else
pn := NIL;
svc := ServiceType;
ps := PUTF8String(svc);
CheckAPIResult(DNSServiceRegister(fHandle,
flags,
0 { interfaceID - register on all interfaces },
pn,
ps,
NIL { domain - register in all available },
NIL { hostname - use default },
ReverseBytes(Port),
0 { txtLen },
NIL { txtRecord },
DNSServiceRegisterReply,
self));
TBonjourEventHandler.Create(fHandle);
end;
This is more verbose than I think it strictly needs to be, certainly it was working perfectly well in Delphi 7 in a much less verbose form. I have expanded a lot of operations into explicit steps to facilitate debugging, e.g. to be able to identify any implicit transforms of string payloads that may be occuring "under the hood" in Delphi 2009.
Even in this untidy expanded form this code compiles and works perfectly well in Delphi 7, but if I compile and run with Delphi 2009 I get no announcement of my service.
For example, if I run this code as part of a Delphi 7 application to register a _daap._tcp
service (an iTunes shared library) I see it pop-up in a running instance of iTunes. If I recompile the exact same application without modification in Delphi 2009 and run it, I do not see my service appearing in iTunes.
I get the same behaviour when monitoring with the dns-sd command line utility. That is, service code compiled with Delphi 7 behaves as I expect, compiled in Delphi 2009 - nothing.
I am not getting any errors from the Bonjour API - the DNSServiceRegisterReply callback is being called with an ErrorCode of 0 (zero), i.e. success, and if I supply a NIL name parameter with AutoRename specified in the flags then my service is allocated the correct default name. But still the service does not show up in iTunes.
I am at a loss as to what is going on.
As you might be able to tell from the expansion of the code, I have been chasing potential errors being introduced by the Unicode implementation in Delphi 2009, but this seems to be leading me nowhere.
The code was originally developed against version 1.0.3 of the Bonjour API/SDK. I've since updated to 1.0.6 in case that was somehow involved, without any success. afaict 1.0.6 merely added a new function for obtaining "properties", which currently supports only a "DaemonVersion" property for obtaining the Bonjour version - this is working perfectly.
NOTE: I'm aware that the code as it stands is not technically UTF8-safe in Delphi 7 - I have eliminated explicit conversions as far as possible so as to keep things as simple as possible for the automatic conversions that Delphi 2009 applies. My aim now is to get this working in Delphi 2009 then work backward from that solution to hopefully find a compatible approach for earlier versions of Delphi.
NOTE ALSO: I originally also had problems with browsing for advertised services, i.e. identifying an actual iTunes shared library on the network. Those issues were caused by the Unicode handling in Delphi 2009 and have been resolved. My Delphi 2009 code is just as capable of identifying an actual iTunes shared library and querying it's TXT records. It's only this service registration that isn't working.
I must be missing something stupid and obvious.
Does anyone have any ideas?!
UPDATE
Having returned to this problem I have now discovered the following:
If I have a pre-D2009 and a D2009+ IDE open (e.g D2006 and D2010) with the same project loaded into both IDE's concurrently:
- Build and run under 2006: It works - my service announcement is picked up by iTunes
- Switch to D2010 and run (without building): It does a minimal compile, runs and works.
Do a full build in D2010: It stops working
Switch back to D2006 and run (without building): It doesn't work
- Do a full build in D2006: It works again
Does this give anyone any other ideas?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
这个问题的答案令人难以置信。一方面,我犯了一个完全愚蠢、非常简单的错误,但另一方面,据我所知,它永远不会在任何版本的 Delphi 中工作!
该问题与任何字符串的 Unicode/非 unicode 性无关,但实际上是由于 PORT 参数中的类型不匹配造成的。
我传入了 ReverseBytes(Port) 的结果 - 该参数需要一个 uint16_t,即 Word 值。然而,我的Port属性被(懒惰地)声明为Integer!!
一旦我解决了这个问题并将Port声明为Word,它现在就可以在Delphi的D2007-和D2009+版本上运行。
很奇怪。
我只能认为,当引入 Unicode 支持时,编译器的一些其他边缘情况行为可能会以某种方式影响这一点,这些行为已被更改。
The answer to this is mind boggling. On the one hand I made a completely stupid, very simple mistake, but on the other hand it should never - as far as I can see - have worked in ANY version of Delphi!
The problem was nothing what-so-ever to do with the Unicode/non-unicodeness of any strings, but was actually due to a type mismatch in the PORT parameter.
I was passing in the result of ReverseBytes(Port) - that parameter expected a uint16_t, i.e. a Word value. My Port property was however declared (lazily) as an Integer!!
Once I fixed this and had Port declared as a Word, it now works on both D2007- and D2009+ versions of Delphi.
Very weird.
I can only think that some other edge-case behaviour of the compiler that might have somehow affected this was changed when Unicode support was introduced.
根据我们此处提供的信息,情况是这样的:
从逻辑上讲,差异必定是 Delphi 2009 将不同的值作为参数发送。为了使调试真正独立于 Delphi,您需要创建一个虚拟 DLL,它报告它获得的值。可以应用其他依赖于 Delphi 的方法,例如查看 DLL 中函数调用的反汇编,并对其进行调试,以便我们准确地知道在两个编译器中将哪些值传递到 DLL,以及如何传递到 DLL。
Based on the information that we have available here, the situation is this:
Logically, the difference must therefore be, that Delphi 2009 sends different values as parameters. In order to make the debugging truly Delphi-independent, you therefore need to create a dummy DLL, which reports the values it gets. Other Delphi-dependent methods may be applied, like looking at the disassembly of the function-call into the DLL, and debugging it so that we know exactly what values are passed, and how, to the DLL, in both compilers.
我在代码示例中找不到变量“ServiceName”和“ServiceType”的声明指令。
假设 String 类型(因此是 unicode 字符串),我猜(是的...没有 D2009 可用于测试这一点)惰性类型转换可能是一个问题:
为什么不使用以下内容?
无论如何...只是我的2克拉。
顺便提一句:
我总是使用预定义的“EmptyStr”、“EmptyWideStr”...所以测试看起来像:
这应该是安全的并且避免类型混淆。
另一方面,Delphi 可能会将 '' 解释为 ANSIChar,就像下面的声明一样:
不确定...我很困惑 - 现在应该回家了;)
I can't find the declaration instruction for the vars "ServiceName" and "ServiceType" in your code sample.
Assuming a String type (thus a unicode string), I guess (yes... no D2009 available to test this) lazy typecasting could be an issue:
Why not use the following?
Anyhow... just my 2 cts.
BTW:
I always use the pre defined "EmptyStr", "EmptyWideStr" ... so the test would look like:
which should be safe and avoid the confusion of types.
On the other side, Delphi may interpret the '' as an ANSIChar like the following declaration do:
Not sure... I'm confused - should go home now ;)
如果 DLL 不是使用 Delphi 2009 编写的,您可能需要使用 PUTF8String 以外的其他内容。 Delphi 2009 Utf8String 类型与Delphi 2007 的UTF8String 类型不同。
如果DLL是使用C/C++编写的,我强烈建议使用PAnsiChar()而不是PUtf8String。
If the DLL is not written using Delphi 2009, you may want to use something else than PUTF8String. The Delphi 2009 Utf8String type is different from Delphi 2007's UTF8String type.
If the DLL was written using C/C++, I strongly suggest to use PAnsiChar() instead of PUtf8String.