Re: Wine and industrial communication like OPC
Mike (at yet another email address) wrote:
Wines sockets support is good though, far better than its builtin DCOM. Based on what I know of the DCOM network protocol, I don't think we'd have any problems with it.
I can think of a couple, but they may be able to be worked around: - incoming connections (DCOM servers) won't be supported. If this guy's clients are going with WinCE that won't be an issue, it doesn't support them either AFAIK. - only DCOM over TCP is likely to be supported. DCOM over named pipes definitely wouldn't be. --Juan _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush
- only DCOM over TCP is likely to be supported. DCOM over named pipes definitely wouldn't be.
Named pipes is ncalrpc yes? This OPC thing sounds more like a network protocol. Or can named pipes go over the wire as well? If so that's a bit scary ... what sort of protocol would they use? thanks -mike
Named pipes is ncalrpc yes? This OPC thing sounds more like a network protocol.
Sorry, I understand now. We use local named pipes to implement (local) DCOM internally but ncalrpc on windows is actually implemented using NT ports. So named pipes via SMB/CIFS ... yeah, I doubt we could do that anytime soon :) Bizarre stuff. What's confusing is that CreateNamedPipe on msdn doesn't talk about networking at all, and there's no parameters to deal with hostnames.
Mike Hearn wrote:
Named pipes is ncalrpc yes? This OPC thing sounds more like a network protocol.
Sorry, I understand now. We use local named pipes to implement (local) DCOM internally but ncalrpc on windows is actually implemented using NT ports. So named pipes via SMB/CIFS ... yeah, I doubt we could do that anytime soon :)
Samba has already documented the protocol and if it wasn't for licensing issues it would be very easy to port it into Wine.
Bizarre stuff. What's confusing is that CreateNamedPipe on msdn doesn't talk about networking at all, and there's no parameters to deal with hostnames.
I think you can just use UNC paths. The same applies for mailslots too IIRC. Rob
Samba has already documented the protocol and if it wasn't for licensing issues it would be very easy to port it into Wine.
Well, how easy is very easy? What I meant is that it's unlikely to be something you could do quickly unless you were familiar with the code in question. It'd be a tragedy to reimplement all that of that code because of GPL vs LGPL concerns. I guess they can't just add an exception clause without consulting every single one of their contributors. Given the ports problem, maybe the solution is just to have smbd expose an interface that lets you manage named pipe connections through it. Not thought about this problem much though.
I think you can just use UNC paths. The same applies for mailslots too IIRC.
I suppose that makes sense, yes.
--- Mike Hearn <m.hearn(a)signal.QinetiQ.com> wrote:
It'd be a tragedy to reimplement all that of that code because of GPL vs LGPL concerns.
I agree. Andrew Bartlett did too in an email he sent me. The reason I've backed off from this is that it's hard to do correctly, and anything less than completely correct isn't going to be accepted by A.J. Ideal for us would be a file descriptor that we can do atomic operations on; that'd be duplicable like the rest of our handles. Not sure how we'd get that from smbd (see below for a different idea), and Samba3's public API is too high-level to be of much use to Wine. (Samba4 might be better.)
Given the ports problem, maybe the solution is just to have smbd expose an interface that lets you manage named pipe connections through it. Not thought about this problem much though.
The ports issue prevents us from receiving connections, i.e. acting as a DCOM server. This is probably less important than being able to act as a client, at least for a while. I asked Steve French (Linux CIFS module) whether he'd consider exposing named pipes in the Linux filesystem. He said he would, then asked me whether I'd given any thought to naming convention. I hadn't and I haven't had as much time to experiment with this of late, so I haven't responded. This method would allow us to act as a CIFS (TCP port 445) client. Acting as an SMB (TCP port 139) client isn't handled by the CIFS module, it's done by the SMBFS module. Not sure what Steve's plans are here. Anyway, any of you guys interested in seeing RPC work under Wine (Greg, you still lurking around here?) might want to play around with this if you have time. I might myself once I land somewhere for a while, but no promises. --Juan __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail
On Thursday 02 September 2004 10:27 am, Juan Lang wrote:
Greg, you still lurking around here?
Yes. But I am worthless atm due to being totally swamped in preparation for going overseas to study. Unfortunately, I am not optimistic about how much time I will have once I am a student... however, eventually I will return to wine work -- I may not remember how to code but I'll be back :). In the meantime y'all are doing a great job of fixing my bugs :P ... I figure I can get y'all to complete my work at about a 50% rate just by ignoring it... Anyhow I have nothing positive to contribute to the discussion... the idea of hacking samba/kernel instead of wine is interesting though, I never gave that much thought but it sounds like a potentially quite effective approach. -- gmt
participants (5)
-
Gregory M. Turner -
Juan Lang -
Kevin Koltzau -
Mike Hearn -
Robert Shearman