Passing Hashtable between server/client

[asmith3006]

Hi, I'm looking to write a server/client system and I want to pass a hashtable between the two. I've found lots of tutorials on making a "Chat" system which passes strings, but how can I increase this to hashtables?

Thanks.

Andrew.

[sknake]

A hash table cannot be serialized but you can move the keys and values over to an array and use the XmlSerializer to get a byte[] array and then base64 encode the bytes to send it across the network as string.

This should get you started:

object[] keys = new object[table.Count];
      object[] values = new object[table.Count];
      table.Keys.CopyTo(keys, 0);
      table.Values.CopyTo(values, 0);

[asmith3006]

Maybe I'm going about this the wrong way, so I'll give you some more detail and hopefully you can point me in the right direction.

I want to have multiple people connecting to a server app (which I will make as a Windows Service) which will display lots of different data, including a timer (i.e. the number increases every second).

What is the best way to pass the data between the server and the clients. Ideally I only want to pass changes over. Is this possible?

Thanks

Andrew.

[sknake]

Well if you're storing data why don't you use an SQL Server to communicate the data instead of writing all of the logic yourself? And for transmitting only modified data you have a few flavors -- a person could modify the data on computer A and send it to the server but when he refreshes next that would not be a modified row since he modified it, and has the modified copy. However person B would need to receive an updated row.

Then you get in to maintaining data "versions" for the server and client apps which add overhead and in some cases the overhead of sending modified data may exceed usefulness of just sending all data.

there are a lot of factors to consider though -- What type of data is this? How is it stored? How much data is there? How many clients? Will this operate over a LAN or WAN?

I think you need to elaborate a little more

[serkan sendur]

http://blogs.techrepublic.com.com/howdoi/?p=143

[asmith3006]

Well if you're storing data why don't you use an SQL Server to communicate the data instead of writing all of the logic yourself? And for transmitting only modified data you have a few flavors -- a person could modify the data on computer A and send it to the server but when he refreshes next that would not be a modified row since he modified it, and has the modified copy. However person B would need to receive an updated row.

Then you get in to maintaining data "versions" for the server and client apps which add overhead and in some cases the overhead of sending modified data may exceed usefulness of just sending all data.

there are a lot of factors to consider though -- What type of data is this? How is it stored? How much data is there? How many clients? Will this operate over a LAN or WAN?

I think you need to elaborate a little more

I think I agree with you.

The system is quite unusual, there will be exactly three clients and the server will be feeding data into another system, so the idea was the server would act as a control gate.

The system is going to be LAN based. Would it be acceptable for the three clients and the "server" to each access the SQL DB every half second? I guess if I went with SQL it would actualy be 4 clients.

[sknake]

Yes .. SQL is capable of handling concurrency but I do not think every half second is a good idea. What data could you possibly have that is so valuable to be refresh that fast? It probably takes about 1/2 a second to fire off a request for data, get it, update control values, and repaint the screen. You're going to pound whatever systems use this.

[asmith3006]

This is why I thought an asynchronous client/server would be better so it can transmit changes.

This system is controlling auctions and presenting auction statistics while changing websites. At most I think I could drop it down to 1 second refresh. Is this still too much?

[sknake]

Regardless of the client -- you have to establish a network command, or send data over an existing connection. Why don't you explain your entire project with the sites, why you have 4 clients, etc? I'm still having a hard time thinking this could be a good idea

[asmith3006]

It's hard to explain as it's a company project so I can't really mention details.

Basically three screen will control an auction on a website with the website changing to reflect the commands sent from the three controllers and from the public's bids.

The controllers will show data such as product information, ellapsed time, images and information about current bidders. The controllers also have buttons to change the price on the websites and to close the auction. In all there is about 30 pieces of data and 15 different ways each controller can interact with the website.

Does this help?

Sorry for being so vague.

[sknake]

Sort of. I would use an SQL Server and have everything using the same table that way you don't run the risk of your database getting desynched from the "server" app, and clients could also be desynched. I think you should just use a database here.