Did anyone else have any thoughts on this?
What Chris and I have come up with so far is pretty much the following:
- Have the basic network interfaces simply provide methods for anything
needed by the main receive loop. (receive a packet, etc.)
- Create a default implementation of the main receive loop which creates a
new thread to handle incoming packets and create events for them. (using the
main CS event queue)
Are there any thoughts on this design?
On Thu, Mar 27, 2008 at 3:43 PM, David Bronke <[EMAIL PROTECTED]> 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
> Support Web Standards! http://www.webstandards.org/
--
David H. Bronke
Vice President of Project Development
G33X Nexus Entertainment
http://www.g33xnexus.com/
v3sw5/7Hhw5/6ln4pr6Ock3ma7u7+8Lw3/7Tm3l6+7Gi2e4t4Mb7Hen5g8+9ORPa22s6MSr7p6
hackerkey.com
Support Web Standards! http://www.webstandards.org/
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Crystal-main mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-main
Unsubscribe: mailto:[EMAIL PROTECTED]
