ToDo: Networking
LANS
- add no-data message handling to the client side
- Find somewhere to store a stable variable (one that is consistent
from the time the app launches until it quits. Where should I store
it?)
- Implement a counter that increases this variable once per no-data
message (no-data messages are created when a bad message is recieved)
- Set up a way to either kick the client or disconnect from the host
when enough bad messages are recieved (what should the limit be?)
- Implement RSA key generation on application startup
- Implement blowfish key generation on server startup (do these need
to be different for each client?)
- Make the client send its public RSA key to the server when
connecting, so the server can encrypt the blowfish key with RSA and
return it to the client.
- implement blowfish encryption of all messages after the connection
is established
- efficientize everything.
And that's all I can think that needs to be done on the low-level
networking side.
Alastair Lynn
On 27 Nov 2008, at 17:17, LANS wrote:
>
> This is my todo list for the network stuff.
>
> - add no-data message handling to the client side
>
I thought that was already in place, unless I misunderstand you.
> - Find somewhere to store a stable variable (one that is consistent
> from the time the app launches until it quits. Where should I store
> it?)
A static variable in NetClient.cpp (or NetServer.cp)
>
>
> - Implement a counter that increases this variable once per no-data
> message (no-data messages are created when a bad message is recieved)
> - Set up a way to either kick the client or disconnect from the host
> when enough bad messages are recieved (what should the limit be?)
>
Ideally: 5, or 2 within 10 seconds.
> - Implement RSA key generation on application startup
> - Implement blowfish key generation on server startup (do these need
> to be different for each client?)
Yeah, they do.
> - Make the client send its public RSA key to the server when
> connecting, so the server can encrypt the blowfish key with RSA and
> return it to the client.
> - implement blowfish encryption of all messages after the connection
> is established
Indeed, indeed.
> - efficientize everything.
That's the easy bit.
> And that's all I can think that needs to be done on the low-level
> networking side.
The most important thing is the error checking: I might suggest you
focus on that before the security aspect, but that's your call and
it's great that you're getting things working! Cheers.
Alastair
LANS
> Hi Andrew-
>
> On 27 Nov 2008, at 17:17, LANS wrote:
>
>
>
> > This is my todo list for the network stuff.
>
> > - add no-data message handling to the client side
>
> I thought that was already in place, unless I misunderstand you.
>
only the server knows what to do with them so far. The client will
probably choke, but I'm not too sure how it would handle it.
> > - Find somewhere to store a stable variable (one that is consistent
> > from the time the app launches until it quits. Where should I store
> > it?)
>
> A static variable in NetClient.cpp (or NetServer.cp)
>
>
>
> > - Implement a counter that increases this variable once per no-data
> > message (no-data messages are created when a bad message is recieved)
> > - Set up a way to either kick the client or disconnect from the host
> > when enough bad messages are recieved (what should the limit be?)
>
> Ideally: 5, or 2 within 10 seconds.
> > - Implement RSA key generation on application startup
> > - Implement blowfish key generation on server startup (do these need
> > to be different for each client?)
>
> Yeah, they do.
entry for each client. I'll set it at 16 for now, and we can make it
bigger later.
> > - Make the client send its public RSA key to the server when
> > connecting, so the server can encrypt the blowfish key with RSA and
> > return it to the client.
> > - implement blowfish encryption of all messages after the connection
> > is established
>
> Indeed, indeed.
>
> > - efficientize everything.
>
> That's the easy bit.
>
> > And that's all I can think that needs to be done on the low-level
> > networking side.
>
> The most important thing is the error checking: I might suggest you
> focus on that before the security aspect, but that's your call and
> it's great that you're getting things working! Cheers.
>
> Alastair
>
> 5KViewDownload
What else is needed for error checking? We have no criteria as to what
messageIDs will be yet, so I can't check if they are allowed, and
because we don't know what data will be transmitted back and forth, I
can't set a maximum message size. Once we have the multiplayer stuff
worked out, I can add error-checking for those two. I assume eNet
takes care of in-transit packet corruption, otherwise we'll need to
add a checksum to the Message() struct.
-Andrew (LANS)
Alastair Lynn
On 27 Nov 2008, at 19:51, LANS wrote:
>
> On Nov 27, 12:22 pm, Alastair Lynn <arpl...@gmail.com> wrote:
>> Hi Andrew-
>>
>> On 27 Nov 2008, at 17:17, LANS wrote:
>>
>>
>>
>>> This is my todo list for the network stuff.
>>
>>> - add no-data message handling to the client side
>>
>> I thought that was already in place, unless I misunderstand you.
>>
> - No-data messages will be created for both the client and server, but
> only the server knows what to do with them so far. The client will
> probably choke, but I'm not too sure how it would handle it.
>
>>> - Find somewhere to store a stable variable (one that is consistent
>>> from the time the app launches until it quits. Where should I store
>>> it?)
>>
>> A static variable in NetClient.cpp (or NetServer.cp)
>>
>>
>>
>>> - Implement a counter that increases this variable once per no-data
>>> message (no-data messages are created when a bad message is
>>> recieved)
>>> - Set up a way to either kick the client or disconnect from the host
>>> when enough bad messages are recieved (what should the limit be?)
>>
>> Ideally: 5, or 2 within 10 seconds.
> - Can I use the time.h library or is there a better way?
Utilities/GameTime.h has a function for getting the time since app
launch in seconds (as a floating-point number).
Checking the validity of message IDs is not a function of that
particular piece of net code - that's higher level, should be handled
in Lua. Making sure that message IDs consist of only the characters A-
Z, a-z, 0-9 and _ might be sensible though, for sending as well as
receiving. eNet puts a CRC32 on each packet, as does UDP, as (I
believe) does IP, so there's error checking at three levels of the
model wrt corruption.
Alastair
LANS
messages have been recieved and kick/disconnect if 5 bad messages are
recieved (or 2 in 10 seconds)
However, I'm really tired as I'm posting this (and I've been slowly
tiring as I coded it), so I'm not 100% sure I did it right and it
still needs to be tested. Could someone please have a look over the
badMessage and badMsg parts of Client.cpp and Server.cpp? I've
uploaded my changes to the git.
Thanks,
-Andrew
ps: I accidentally commited under "Admin", not LANS
> 5KViewDownload
Alastair Lynn
compile. That's bad. Very bad. Please don't ever do that again.
If you need code debugged, upload it to a new branch, and please at
least compile it on your machine even if you don't test it, to make
sure that it does compile.
Alastair
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "Xsera Development" group.
> To post to this group, send email to xser...@googlegroups.com
> To unsubscribe from this group, send email to xsera-dev+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/xsera-dev?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
LANS
> 5KViewDownload
Alastair Lynn
I put that a bit more explosively than I should have. If you could
push to a different branch (not a different fork!) in future, that
would be great. You can do that by doing 'git push origin
master:network-error-checking" (or replace network-error-checking with
whatever) as opposed to just 'git push'. The 'master' branch is for
working code :P
Alastair
LANS
and tested this morning before I realized you did it, so I've decided
not to change yours (mine ended up being the same as yours with a few
slightly different variable names)
I can't always get a machine to compile on, and quite often I'm using
textMate, not Xcode. My dad's macbook (which runs leopard) refuses to
follow #include-s. I have an external HD with leopard for a G4 700
which my mom uses, but its not often I can boot into it to do a test
compile. Luckily, I recently got my grandma's old G5 iMac, but I can't
do anything with if for a few weeks until she's sure we transferred
all of her files over (even though everything was sent over, but
that's fine).
Next up: Making sure MessageIDs only contain A-Z, a-z, 0-9, and _.
-Andrew
> 5KViewDownload
LANS
someone please revert it for me? I can't figure out how.