RE: [Plib-devel] Networking Code

[Ben W. <be...@bg...>]

Hello Sam,
 
First I want to get everything running and portable before I start thinking
about overloaded constructors. I am trying to keep everything nice and
simple. Also I would like to hear what dave thinks of the idea. 
But I do have good news, I am slowly getting through the OpenTransport stuff
for macs, who ever said that sdl net uses Open Transport, I read the docs on
it and things are moving along alot better now. 
 
Later Ben
ps There are a few things that I don't understand, all the examples are done
in c and a few of the memcopy sections and things like that I have been
having problems with, if someone could give me a hand with thoughs sections
it would help alot. 
 

-----Original Message-----
From: Sam Stickland [mailto:sa...@sp...]
Sent: Tuesday, August 22, 2000 1:11 PM
To: pli...@li...
Subject: Re: [Plib-devel] Networking Code


 

----- Original Message ----- 
From: Dave McClurg <mailto:Dav...@dy...>  
To: 'pli...@li...'
<mailto:'pli...@li...'>  
Sent: Tuesday, August 22, 2000 4:08 PM
Subject: RE: [Plib-devel] Networking Code


Hi Ben, 

In adding networking code to plib, I recommend keeping it simple like the
code you showed me from tuxkart.  We just need a portable way to setup a
connection.  The application code should be responsible for the rest.

A turn based game doesn't need dead-reckoning so setPos() probably doesn't
belong in plib proper.

Yes, that's certainly the case.  I hadn't ever really considered making the
full network library I'm working part of plib - I wanted it to be a stand
alone affair.  If it uses portable socket code in plib that's fine by me
though.

I'd personally be in favour of this structure for the socket library.

TCPSocket *mysock_con                  = new Socket(1234); // Create a new
socket on port 1234 on the server

TCPSocket *mysock_client_to_server = new Socket('spacething.org', 1234); //
Client attempts to connect to spacething.org on port 1234

TCPSocket *mysock_server_to_client = new Socket(mysock_con); // Server
accepts the client connection

But that's me.  Actually one disadvantage in the above system is that you
can't easily return errors in constructors without using exceptions - ugh.
Best to seperate out the constructor and initialisation code if you went
with the above.

Things like real-time state management or match-making systems for finding
opponents could be placed in an auxillary library.