[Dima-san]

It's an another minor release, yet important one.

Things implemented:

• packet sequencing
  
• reliable data delivery
  
• flow control (that is, packet transmission frequency is based on available bandwidth)
  

Stuff to be implemented in the nearest future:

• message fragmentation/assembly
  
• packet loss/latency simulation
  
• simple object distribution framework
  

PS: I apologize for late post

[bane]

Mr. Dima-san is too modest with his apologize, considering the great job he is doing with dnet
_________________
"I apologize only for my spelling" - a quote shamelessly stolen from some guy at unknown forum.

[h3r3tic]

Nice! You guys are progressing pretty fast We might try using DNet in Deadlock, as a networking backend alternative to RakNet. I can't promise anything yet, because we've got lots of issues to resolve and everyone in team0xf has his personal timelines external to Deadlock.

Anyway, I've quickly browsed thru the code and found a few 'issues':

- a bit too much dynamic memory allocation thru the GC
- the use of char[] for raw data instead of byte[] / ubyte[]
* char[] is meant for utf-8 strings, not binary data, ubyte[] is more self-explanatory
- '( 0 << 1 )' in connection.d is baffling...
* shouldn't that be '(1 << 0)' ?

Except for the first thing, they are rather minor issues. Additionally, are you planning Tango-compatibility?

Keep up the good work!

[Dima-san]

h3r3tic
> a bit too much dynamic memory allocation thru the GC
I know. That'll be eliminated pretty soon.
> * shouldn't that be '(1 << 0)' ?
You're right Thank you for noticing.
> char[] is meant for utf-8 strings
You're right once again, but that way packet data can be printed to stdout without casting. bane gets lazy when it gets to typecasting
>Additionally, are you planning Tango-compatibility?
We do, but that'll have to wait.

[h3r3tic]

[Dima-san]

>You could have a function that prints it
Yeah, I could.
Anyway, I fixed that. No more char[]s.

[h3r3tic]

Wheee