Suitability of custom formatting for interoperability

[drewnoakes]

Hi,

I'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.

[Robert Jordan]

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

[Lloyd Dupont]

> 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 uh?
you can't do remoting with C++ / Java. Remoting is .NET specific.
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
whether I can leverage the server support of IIS rather than write my own

you can leverage IIS for WebServices

[drewnoakes]

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.

"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

[Robert Jordan]

Hi,

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).
Writing a custom formatter won't solve your problem. You'd also need
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

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