Coffeehouse Thread

4 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Difference between using remoting and a NetworkStream

Back to Forum: Coffeehouse
  • User profile image

    Hi all, I created an application using NetworkStreams and TcpClient in order to connect to the same application running on a different PC over the network.
    It all started as a test and became my application "communication protocol". The thing is, I recently dug on Remoting and found it quite interesting. Now I can do more than just send text over the network, I can send instances of my own objects.
    But, despite that, what are the main differences between using Remoting or the NetworkStreams? What about performance?
    Using the TcpClient I can't run two instances of my app on the same machine cause the TCP port used by one instance cannot be used by the other. Could I do that with Remoting?

    Any good experiences to share?

  • User profile image

    Actually Remoting is "basically" using binary serializer over NegotiatedStream for security.  Remoting gives you all the abstractions to make it easier, but you could do things like marshal your objects yourself using binaryserializer (I have done this and works well).  I could be me, but I ran into some dead end with remoting and connecting to multiple machines at same time because the channel takes your credentials so you need to somehow use different tcp channels which I could not figure out how to do.  Also, things like streaming large data is a challenge with remoting, but simple with NetworkStream.

    You can have any number of client apps on your machine connecting to same host/port and/or different host/ports.  Remember with TCP sockets 1 out of 4 things needs to be unique.  source IP/source port/dest IP/dest port.  So you can have N clients using different source ports all connecting to same hostip/port and all works fine.  When you "connect" don't bind an ip/port, but let it pick dynamically on the client side - it will pick a free port.

    Remoting is a fine tech and may be the right choice.  It is not without its own large learning curve, however, especially when you start to push beyond a simple request/reply.  At some point MBR and MBV can start to bend your mind as your app gets more complicated.  You may then get to the point of saying "hey, this would have been easier to just have the stream and pass my own messages back and forth."  At least the stream has very simple semantics.  You do end-up re-creating ~some of the Remoting wheel, but can actually be easier depending on what your doing.  I created a simple Message<T> stream that takes a NetworkStream.  Then I can send and receive any [serializable] class back or forth with ease.  So I guess there is not one right answer here.  It depends on your needs.  What are you doing?

  • User profile image

    Great tip, thanks!
    It all started as a test and a IM application.

    I understand what you say about the ip addresses and ports, but my problem is that I have TcpListeners in one port of my computer and I can't have another programm in the same computer listening on the same port. That's why I can't have two intances of the same app running on the same computer.

    I'll try to chage at least some of the communications to remoting, but, from what you've told me, I'll keep the file transfering functionality with my NetworkStream.


  • User profile image

    Have you thought of using WCF?  This is the way to do it.

    Go to

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.