3

I am attempting to send player information from my Game to my network client to then be sent off to the server.

Currently the ClientNetwork -> ClientGame relationship is held with XML files. They read/write back and forth at very high speeds. If you use just one XML file for this trade, one will "hog" the file at times, making a kind of lag when one cannot read because the other is viciously writing and rewriting.

To fix this I have 2 of each of my XML files. If it cannot read one, it will read the other. In theory they should be using both of them, since it'd be a tradeoff from one to another. Not working up to par.

But my main problem is just the usage in general of XML is very sloppy, dozens of try-catch statements to make sure they're all happy (and my personal favorite, try catches within try catches -- WE HAVE TO GO DEEPER)

I am just curious of if there is a better way to be doing this. I need a static point of variables that can be accessed by both client side programs. I'm afraid someone is going to say databases...

I'd like to state for anyone who is looking into this as well and stumbled across this page that Shared Memory is awesome. Though I have to convert all strings to characters and then to bytes and read them one by one, in the whole it's ALOT better than dealing with things that cannot read/write the same file at the same time. If you wish to further understand it rather than just use it, go to this link, it explains a lot of the messaging varieties and how to use them.

Shadow The GPT Wizard
  • 66,030
  • 26
  • 140
  • 208
Remm
  • 677
  • 8
  • 24

3 Answers3

6

Yes there is!

The term you are looking for is interprocess communication - communication between two processes on the same machine.

There are various methods which allow two processes on the same machine to communicate with each other, including:

  • Named pipes
  • Shared memory
  • Sockets
  • HTTP

Fortunately C# applications can simply use the WCF framework to perform IPC (interprocess communication) using one of the above, and let the WCF framework take care of the difficult bits! Here are a couple of guides to get you started (there are many more):

Also, one of the neat things about WCF is that you can also use it to communicate between different machines simply by changing the "Transport" (i.e. the communication method) to one which works over a network, (e.g. HTTP).

If you are targetting .Net 2.0 then you should look into either .Net remoting or web services instead.

Justin
  • 84,773
  • 49
  • 224
  • 367
  • Spot on. Also look at named pipes. – Gian Paolo Apr 07 '11 at 23:26
  • Or Memory Mapped files in .NET 4 – jeffora Apr 07 '11 at 23:32
  • Thanks for the source links. Though I have a feeling any attempt to use this is going to crash and burn: It is a server - client relationship that requires one to be listening for messages from the other and vice versa. I couldn't connect my game to my server to begin with because the game will always 'miss' the messages - or alternately they start spewing error messages at each other faster than the game can read... I think looking into this 'shared memory' might be my best bet -- The variables in the middle have to be always sitting there, rather than a communication stream to be read I gues – Remm Apr 07 '11 at 23:42
  • @Remm It sounds like shared memory is your best bet, but its only available on .Net 4.0. If shared memory doesn't work out then try posting a more specific question about your problems - it should be possible to handle errors by (for example) only retrying every Xms, and keeping a track of variables that have not updated due to failures. – Justin Apr 07 '11 at 23:47
  • 1
    Will do. You win this time, Kragen~ – Remm Apr 08 '11 at 00:09
0

A simple TCP stream jumps out at me. Have the network client open a listening TCP socket, and have the game connect to the network client. You could continue to send the same XML data you're already writing, if you like.

David Yaw
  • 27,383
  • 4
  • 60
  • 93
  • Vaguely sure this is how Lidgren.Net works and let's just say my project doesn't like connecting to pretty much anything, thus this whole 2 executable thing is a huge workaround. – Remm Apr 07 '11 at 23:34
0

I agree with the tcp/ip socket answer proposed by David. I would simply submit the data to a socket on the local pc and have the other application listen to the socket. You can transmit data easily and quickly using this method and it will work no matter what version of the .net framework you are targeting.

Matt
  • 1,168
  • 2
  • 15
  • 24