I haven't worked with CS in awhile, so take this with a grain of
salt :)
If you're working with a class base structure, I'd say use an
interface for callbacks. You should be able to have an interface with
callbacks for New Connection, Connection Closed and Message Received.
Leave the loop to a higher level at first and make a function that
performs your poll. Use poll or epoll (where available) instead of
select. If you're aiming for a MMO you're going to exceed the number of
sockets select can handle.
Once you have that layer, put an implementation on top that
applications can optionally use that runs its own thread. This layer
could also implement the callback interface and map those callbacks into
CS events.
Make sure you allow for some level of control over logging in the
network system separate from the rest of the application. Building
logging in from the start will save a lot of pain.
At the lowest level, I'd make the messages as simple as possible.
Probably just a length followed by opaque data. Make higher level
'routing' code that knows how to handle the data. In this way your low
level code (the ugly bits) can be reused for any message that can be
represented as a sequence of bytes - you could put packed binary data
in, or xml. If you wanted to get fancy you could begin your data with a
marker that indicates whether the rest of the data is binary, xml, or
something else - allowing you to mix different types of messages over
the same connection easily. By adding an interface you can let the
application developer pick or create their own message serializer -
which gives the system a greater chance of meeting the developer's needs.
Andrew
David Bronke wrote:
> Chris and I have been working on the design for our networking plugin
> (which may or may not end up being included in any of the CS/CEL
> repositories; we'll discuss that at a later date) and I've come across
> a couple of design questions I'd like to hear thoughts on. One of my
> goals in this design is to allow the networking plugin to be used in
> as many projects as possible, so we're trying to abstract any parts
> which people might want to change or replace.
>
>
> The biggest question currently is how to tie the network receive loop
> into the API. There's a few approaches to this:
> - have functions in the connection class for all the operations
> needed by the loop, and leave the loop's implementation and thread
> creation up to the app (nice because the app designer has complete
> control over how threading is done)
> - implement the loop in the network plugin and have callback hooks in
> the API to handle incoming packets
> - implement the loop in the network plugin and generate CS events to
> handle incoming packets
>
> I personally like the last option the best (generating CS events based
> on incoming packets) but I could see the merit of a callback system as
> well. Would it be worth making the receive loop a separate interface
> so that part can be swapped out depending on the user's needs? This
> would allow users to substitute a networking loop with a different
> behavior depending on their application's needs.
>
>
> The other question we had come across (which we've already pretty much
> decided on, but would like to pass by the mailing list) is how we want
> to work the networking loop. Again, we have a couple of possibilities:
> - run a separate thread which keeps calling accept()
> - catch CS's idle events or frame events or something, and call
> accept() in a non-blocking fashion (problem: it makes network
> performance directly dependent on framerate)
>
> It will need to be structured around CS's event loop, so our thought
> was that using CS's thread support may be the best option here.
>
>
> Any thoughts?
>
> Thanks,
> --
> David H. Bronke
> Vice President of Project Development
> G33X Nexus Entertainment
> http://www.g33xnexus.com/
>
> v3sw5/7Hhw5/6ln4pr6Ock3ma7u7+8Lw3/7Tm3l6+7Gi2e4t4Mb7Hen5g8+9ORPa22s6MSr7p6
> hackerkey.com <http://hackerkey.com>
> Support Web Standards! http://www.webstandards.org/
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> ------------------------------------------------------------------------
>
> _______________________________________________
> Crystal-main mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/crystal-main
> Unsubscribe: mailto:[EMAIL PROTECTED]
>
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Crystal-main mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-main
Unsubscribe: mailto:[EMAIL PROTECTED]
