Suggestions for general networking solution on WAN and LAN

[farsen]

Hi.

I am about to program a piece of software which contains a single server, and about 20-40 clients.
All parts can be spread out on a lan, or on a wan.
The server shall be able to broadcast/multicast to the clients in some way, and the clients should be able to fetch information from the server.
There are about 30 kinds of information which has to be fetched/broadcasted.

Question is, how to solve this general problem in the most elegant way?
I would be happy if i could avoid switches in the client/server end to check what kind of information i received, or make my own kind of application layer protocol to check it.
I had a look at remoting, like RMI in java, but that seems to be a very bad idea over WAN because of firewalls and such.

Do you have any insight in possible solutions for this?

Thanks alot :)

[sknake]

Just use TCP and forget about broadcast information. Don't implement something of your own, use TCP ;)

For clients connecting to you from the WAN they initiate the connection so you need a port forwarding rule set up on your edge device to route inbound connections to the server from the clients. They should have no issues on their end.

For broadcast you probably don't want to do that. Broadcasting sends the traffic to _every_ IP on the subnet. So if you have 200 computers on the subnet and only 40 participate in this client-server model then the other 160 nodes will still receive the traffic anyway. If you do want to use broadcast you should look in to setting up a 802.1Q/vlan network and run the machines part of the client-server model as tagged on the vlan. You will need a managed switch to set all this up -- and a lot of time to learn about it. You also need to install VLAN support in windows (varies by version, but it is well documented) and configure the machines to run tagged on the broadcasting subnet. The switch port should run their primary network untagged and the broadcast network as tagged.

[farsen]

Thank you for the reply.
I have no intention for replacing TCP ;) What I meant was how to sort and handle the different kind of information i send back and forth between server and client. Either by making an application protocol (maybe stateful which is troublesome), that works as an upper layer on TCP, or a looong switch that checks if it is this kind of information, or this kind of information and so on. Not that elegant.
You are right, broadcast would not be a good idea ;) But if it is possible to use some kind of multicast?

I am not interested in using any kind of special networking setup on the client side.

Thank you for your time :)

Just use TCP and forget about broadcast information. Don't implement something of your own, use TCP ;)

For clients connecting to you from the WAN they initiate the connection so you need a port forwarding rule set up on your edge device to route inbound connections to the server from the clients. They should have no issues on their end.

For broadcast you probably don't want to do that. Broadcasting sends the traffic to _every_ IP on the subnet. So if you have 200 computers on the subnet and only 40 participate in this client-server model then the other 160 nodes will still receive the traffic anyway. If you do want to use broadcast you should look in to setting up a 802.1Q/vlan network and run the machines part of the client-server model as tagged on the vlan. You will need a managed switch to set all this up -- and a lot of time to learn about it. You also need to install VLAN support in windows (varies by version, but it is well documented) and configure the machines to run tagged on the broadcasting subnet. The switch port should run their primary network untagged and the broadcast network as tagged.

[sknake]

Multicast doesn't do what you want it to either. Just use remoting and away you go. You can have 30 methods to handle the 30 inputs and broadcast that out, or you can prefix the command with "XX data here" and parse "XX" out and switch on it. I suppose that is a matter of preference but I would use the numerical route and switch on it so all of your inbound comms come through a single method. From the switch just delegate it out for whatever 'special task' you need to have done.

[farsen]

"Just use remoting and away you go" ... I thought remoting was not possible on WAN unless you configered the client side´s routers? Or am i wrong?

Hmm, so i guess there arent a more elegant way than having one or a couple of long switches :(

By the way, I´ve head that WCF (Windows Communication Foundation) should be easier and better to work with in C#, instead of ordinary sockets and alike. Is that correct?

[sknake]

You don't have to worry about client side routers. Say your setup your remoting to hit "myoffice.mydomain.com:xxxx"

client --> his firewall -- > interwebs --> your router (port forward) --> your server

You only need to set up a port forwarding rule on your router to NAT the packet to the server inside of your network. Unless the client has egress filtering (possible, but rare) then they will not need to make any changes. To get around egress filtering you could run your server on TCP/80 but then if they have a network-wide PROXY (somewhat common) then it will break your TCP remoting, you will have to use HTTP remoting.

If you have an IIS server laying around I would set up HTTP remoting. It will probably be the most-supported method of remoting. If not I would run a TCP Remoting Server on a TCP port < 1024.

[farsen]

client --> his firewall -- > interwebs --> your router (port forward) --> your server

Yes, but when I am using events im remoting to "multicast" information to the clients, the clients suddently become "servers", and thats where we have the problem. Or am i not right?
If i am right, this could of course be solved with a timer solution so the clients checks with intervals if there are any new information on the server. But then again, that aint a very elegant solution ;)

[sknake]

I thought you weren't going to use multicast? Read about multicasting:
http://en.wikipedia.org/wiki/IP_multicast

You need routers/switches smart enough to manage the IGMP requests for subscribing to a multicast address. I will be amazed if this works widespread. This is also a 'stateless' approach to remoting. You may have problems with dropped packets since multicast by nature doesn't request retransmission of data due to data loss, where as with TCP the data will come across as-expected or the connection will be shut down.

[farsen]

Ok, so multicast/events is out of the picture!

So i guess Im up with either remoting with timerbased client-fetch-data solution, or ordinary tcp sockets with switches to sort out and handle incomming data. :|

By the way, I´ve head that WCF (Windows Communication Foundation) should be easier and better to work with in C#, instead of ordinary sockets and alike. Is that correct?

[sknake]

You can use an event-based model with remoting. Check out this sample project demonstrating the concept in three different ways:
http://www.codeproject.com/KB/IP/remotingandevents.aspx

As far as WCF i'm not sure. I haven't used/read about it.

[farsen]

Well that is just as good as multicasting i guess! It seems to fit my needs, so I will go on with it.
Thanks alot!