Do you guys think CSLA would be a good fit in a UDP networking infrastructure? I am using CSLA at work as we all like the framework and ease of code generation it allows. At home I work on various hobby applications, one of which is a client/server game using UDP.
Admittedly, it's mostly in design and planning ATM and I am investigating frameworks for it and strongly considering CSLA. However, I wonder how well CSLA would scale for UDP over sockets?
Basically, the client performs some action that should get sent to the server for processing and a result is returned to the client (typical). However, the amout of traffic could be very high and sending each command over individually could eat up too much mandwidth (UDP header on each packet for each object). I am thinking that between the client and server I will have sender/listener code (actually on both the client and the server). The client sender code will accumuate non-priority commands into a buffer (for x amount of time or until x data size is reached). Then send this over as a batch. The server simply listens for the batch and processes it. It should be easy to break apart the packet into it's basic business objects. Since CSLA serializes out to a byte stream this seems like it would fit right in. I'm just wondering if the overhead may not be too great. I don't want to progress too far with CSLA just to find out that it isn't fast enough for my needs.
Can provide more detail if helpful.
Thanks,
Will
Hmmm....
Well I guess you could; a few things though to think about:
CSLA as-is was designed to use the network to follow a "request-reply" model
TCP has packet-re-try and such that work to make that model work
UDP is more of a "FIRE and FORGET" model
so you might want to look at what data you are working with and have both a TCP and UDP game connection - UDP for broadcast data
TCP for connected data.
your "OVERHEAD" will be in how you handle packets, binary/ text and such.
Yes, I am aware of the connectionless state of UPD as opposed to connected TCP. I do plan to use both as there are times when packet ordering and guaranteed delivery will be necessary. For the most part though UDP is going to be my primary method. Most of the packets will be things like "User is running forward". This can be sent a bunch of times if the user is holding down the UP arrow. Depending on how I interpret and process. I think it might be better to send a "User is running forward" when the upser presses the UP arrow and then send a "User has stopped running forward" when they release the key. Of course, things like this will have to be checked routinely for cases where the "stop running" packet is dropped on the network, but that's another issue alltogether.
My main concern ATM is whether or not CSLA will be a good fit. Obviously I will need business objects on the client and the server for things like Character, NPC, Item. The server actually sends updates to the client and responds to requests. The client presentation layer simply displays the current state of those business objects and responds to user input. I don't currently see any reason why CSLA won't work out but it's still in design and I'm sure I'm not seeing every facet clearly.
Will
Well, no matter what method I use, the end result will have to be the same. There will be a .dll on the server and one on the client that is a library of the business objects.
For the most part, the finite state of things will be on the server. The client will simply send messages to the server for processing. The server itself can use remoting for it's various layers and that should work just fine.
On the client side, the business objects will be used but the messages between the client and server will not necessarily be serialized business objects (because of the UDP limitation). The client will simply send a message stating something like "Character11334 moved forward". The server would deserialize this packet and update the appropriate business object on it's end with this new information.
Regardless of how this works, I will need a consistent framework on both the client and server.
Also, I will definitely use the framework AS IS for administration applications (data entry and management).
I will investigate building in more functionality to the business objects to handle sending and recieving them over the wire (UDP style). I don't see where it will be very difficult.
Will
P.S. I've got a lot of work done on the templates for C# code generation. Right now I am trying to find where Kathleen embedded the VB comments at the top of each file indicating that it was automatically generated and should not be changed. VB comments don't work so well in a C# application. :)
<EDIT>Found it, TargetLanguage tags in the harness file.</EDIT>
Copyright (c) Marimer LLC