|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Suitability of custom formatting for interoperabilityI'm developing an application server to which clients will connect over the network. This server has a variety of entry points, and remoting seems well suited for those clients written in .NET. However there are two simple functions that will be accessed from unmanaged C++, and possibly Java one day. For these I'm considering utilising a straightforward custom binary protocol. The C++/Java client can open a socket, send request bytes, then marshal the returned bytes into a local structure. I'm comfortable setting up the .NET-to-.NET portion, but am not sure how to go about the interop bit. Do I create another remoting entry-point on a TcpChannel that has it's own binary formatter? If so, what overhead does remoting add to the underlying socket stream? I'm trying to establish whether I can leverage the server support of IIS rather than write my own asynchronous TcpListener server. If I can get remoting to work for simple requests (that return simple structures, such as arrays of floats, strings, etc, all of which are in an agreed upon structure and hence need not be self describing or extensible) without adding many more bytes to the stream than those I control with my FormatterSinks, then coding the equivalent formatter in C++/Java should be easy. Hope this makes sense and that someone can help me out of my confusion here. Kind regards, Drew Noakes. Hi,
> I'm comfortable setting up the .NET-to-.NET portion, but am not sure how to ..NET-Remoting is only suitable for .NET to .NET communications.> go about the interop bit. Do I create another remoting entry-point on a > TcpChannel that has it's own binary formatter? If so, what overhead does > remoting add to the underlying socket stream? I'm trying to establish > whether I can leverage the server support of IIS rather than write my own > asynchronous TcpListener server. If I can get remoting to work for simple > requests (that return simple structures, such as arrays of floats, strings, > etc, all of which are in an agreed upon structure and hence need not be self > describing or extensible) without adding many more bytes to the stream than > those I control with my FormatterSinks, then coding the equivalent formatter > in C++/Java should be easy. Everything else is a world of pain. You're wasting your time. Use web services (if your non-.NET clients are able to act as a web service client) or a simple socket server. Rob Ok, I'll try out the custom binary format over a socket. We don't want to
use web services. If I understand correctly, you're telling me that even if I write custom message formatters (using the same binary format as a socket implementation) the remoting framework adds sufficient extra bytes (header/footer) and/or additional signaling/handshaking as to make calling these functions prohibitiviely difficult. Bear in mind that I don't need any CAO/MarshalByRef functionality -- just an entry point for RPC (singleton SAO). Is this the case? Thanks, Drew. Show quote "Robert Jordan" wrote: > Hi, > > > I'm comfortable setting up the .NET-to-.NET portion, but am not sure how to > > go about the interop bit. Do I create another remoting entry-point on a > > TcpChannel that has it's own binary formatter? If so, what overhead does > > remoting add to the underlying socket stream? I'm trying to establish > > whether I can leverage the server support of IIS rather than write my own > > asynchronous TcpListener server. If I can get remoting to work for simple > > requests (that return simple structures, such as arrays of floats, strings, > > etc, all of which are in an agreed upon structure and hence need not be self > > describing or extensible) without adding many more bytes to the stream than > > those I control with my FormatterSinks, then coding the equivalent formatter > > in C++/Java should be easy. > > ..NET-Remoting is only suitable for .NET to .NET communications. > Everything else is a world of pain. You're wasting your time. > > Use web services (if your non-.NET clients are able to > act as a web service client) or a simple socket server. > > Rob > Hi,
> Ok, I'll try out the custom binary format over a socket. We don't want to Writing a custom formatter won't solve your problem. You'd also need> use web services. > > If I understand correctly, you're telling me that even if I write custom > message formatters (using the same binary format as a socket implementation) > the remoting framework adds sufficient extra bytes (header/footer) and/or > additional signaling/handshaking as to make calling these functions > prohibitiviely difficult. Bear in mind that I don't need any > CAO/MarshalByRef functionality -- just an entry point for RPC (singleton SAO). something like a TcpChannel on the other side, which must be ideally interoperable with MSFT's TcpChannel, of course. SAO/CAO are not the problem here, because they share the infrastructure. If your really want to pull out your hairs in the next months, you may try this: - implement a custom formatter for .NET, - implement a custom TCP channel for .NET - implement the couterparts for Java - implement the couterparts for C++, if you still have some hairs ;-) Rob Show quote > > Is this the case? > > Thanks, > > Drew. > > "Robert Jordan" wrote: > > >>Hi, >> >> >>>I'm comfortable setting up the .NET-to-.NET portion, but am not sure how to >>>go about the interop bit. Do I create another remoting entry-point on a >>>TcpChannel that has it's own binary formatter? If so, what overhead does >>>remoting add to the underlying socket stream? I'm trying to establish >>>whether I can leverage the server support of IIS rather than write my own >>>asynchronous TcpListener server. If I can get remoting to work for simple >>>requests (that return simple structures, such as arrays of floats, strings, >>>etc, all of which are in an agreed upon structure and hence need not be self >>>describing or extensible) without adding many more bytes to the stream than >>>those I control with my FormatterSinks, then coding the equivalent formatter >>>in C++/Java should be easy. >> >>..NET-Remoting is only suitable for .NET to .NET communications. >>Everything else is a world of pain. You're wasting your time. >> >>Use web services (if your non-.NET clients are able to >>act as a web service client) or a simple socket server. >> >>Rob >> > I'm comfortable setting up the .NET-to-.NET portion, but am not sure how you can't do remoting with C++ / Java. Remoting is .NET specific.> to > go about the interop bit. Do I create another remoting entry-point on a > TcpChannel that has it's own binary formatter? If so, what overhead does uh? You haver to use a platform neutral communication protocol for that. Some people choose home made binary format protocol (which would be entirely up to you, down to every single bit), most people choose an existing such protocol: - WebServices - XmlRpc - Corba - HTTP WebService has an excellent support in .NET. And a somewhat acceptable support in other languages. > remoting add to the underlying socket stream? I'm trying to establish you can leverage IIS for WebServices> whether I can leverage the server support of IIS rather than write my own |
|||||||||||||||||||||||