Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / DarkNet

Author
Message
Mike Johnson
TGC Developer
22
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 15th Apr 2009 10:05
We released DarkNet recently -

DarkNet is a multiplayer plugin specifically designed for use in game development. It uses both UDP and TCP protocol making it suitable for virtually any type of online game ranging from fast paced first person shooters to large scale massively multiplayer online games. It is very easy to use and well documented with several code examples. DarkNet is compatible with Dark Basic Professional, C++ and .NET compatible languages (e.g. C#, VB.NET).

More information can be found here -

http://darkbasicpro.thegamecreators.com/?f=darknet
wh1sp3r
21
Years of Service
User Offline
Joined: 28th Sep 2003
Location: Czech republic
Posted: 5th May 2009 20:57
I have question. Can I use this library without using DarkGDK ? Just only c++ and this library.

PS: Real programmers aren't afraid of math!.

AMD 64x 3500+, 6GB RAM, GeForce 8800 GTS 320MB, HD 500GB, X-fi xtreme audio, Internet 10/1 Mbit
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 5th May 2009 22:52
Quote: "I have question. Can I use this library without using DarkGDK ? Just only c++ and this library."

Yes

wh1sp3r
21
Years of Service
User Offline
Joined: 28th Sep 2003
Location: Czech republic
Posted: 9th Jun 2009 00:50
Michael P: so, i have bought darknet...

I tried compile it and I got lot of unresolved errors



I am not using DarkSDK, I am using Leadwerks engine

PS: Real programmers aren't afraid of math!.

AMD 64x 3500+, 6GB RAM, GeForce 8800 GTS 320MB, HD 500GB, X-fi xtreme audio, Internet 10/1 Mbit
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 9th Jun 2009 15:30
Try changing the runtime library to Multi-threaded. In visual studio this option can be found in project properties: Configuration properties -> C/C++ -> Code Generation -> Runtime library -> Multithreaded (/MT).

wh1sp3r
21
Years of Service
User Offline
Joined: 28th Sep 2003
Location: Czech republic
Posted: 16th Jun 2009 23:27
Michael P: Hi, I have another few questions. It's about size of packet.

If I send UDP packet with 4 floats .. packet has 16bytes, or 1024(Setmemorysize) ?

http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

Do you understand, how packet looks like from this web site ? Is it true, that All data updates (players, objects, bullets) are in one packet ?

PS: Real programmers aren't afraid of math!.

AMD 64x 3500+, 6GB RAM, GeForce 8800 GTS 320MB, HD 500GB, X-fi xtreme audio, Internet 10/1 Mbit
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 17th Jun 2009 20:03 Edited at: 17th Jun 2009 20:04
Quote: "If I send UDP packet with 4 floats .. packet has 16bytes, or 1024(Setmemorysize) ?"

The used size is the size of the packet that is sent (in other words, the amount of data that is sent). The memory size is the maximum amount of data that the packet can hold, and thus the maximum value that the used size could be.

So if you add 4 floats, only those floats (16 bytes worth) will be sent, not the entire memory space allocated to that packet.

Quote: "Is it true, that All data updates (players, objects, bullets) are in one packet ?"

I skim read the article and I don't think it specifically mentions whether all updates are done within one packet. It is a matter of preference as to how you do the updates. You could do it with multiple packets or you could do it with one single packet, it doesn't really matter. As for performance, I'm not sure which would perform better.

UDP mode 2 (per client, per operation) is designed to be used with the multiple packet update method and UDP mode 1 (per client) designed for the single packet update method. UDP mode 3 (catch all) can be used with either method and is used in a similar way to TCP.

AlexI
19
Years of Service
User Offline
Joined: 31st Dec 2004
Location: UK
Posted: 17th Jun 2009 23:18
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 18th Jun 2009 01:26 Edited at: 18th Jun 2009 01:27
I have more time now than usual so I am doing quite alot of work. The next version is going to have more than just voice commands, its going to be a big update.

I plan to do the following before the next release:
-Voice commands (almost totally done)
-New UDP mode, the same as 'catch all' (3) but out of order packets are discarded
-HTTP commands
-Windows firewall commands
-Improved error system, with a command that detects when an error has occurred so that you don't have to check the return value of functions (-1 doesn't always indicate error), exception error mode and the ability to use multiple error modes at the same time. (done)
-Improved performance and a couple of minor bug fixes
-Rewrite help files
-Write new demo code
-Create website

So as you can see, I have alot to do. Optimistically I would say it will be ready by the end of June. Pessimistically by mid July. But I promise, it is coming, and when it arrives it will be good .

wh1sp3r
21
Years of Service
User Offline
Joined: 28th Sep 2003
Location: Czech republic
Posted: 18th Jun 2009 19:21
Michael: great

PS: Real programmers aren't afraid of math!.

AMD 64x 3500+, 6GB RAM, GeForce 8800 GTS 320MB, HD 500GB, X-fi xtreme audio, Internet 10/1 Mbit
AlexI
19
Years of Service
User Offline
Joined: 31st Dec 2004
Location: UK
Posted: 18th Jun 2009 23:12
kklouzal
15
Years of Service
User Offline
Joined: 15th May 2009
Location: Arizona
Posted: 23rd Jun 2009 12:18 Edited at: 23rd Jun 2009 12:20
hmmm......

There needs to be a way to set priority on a udp packet so that higher priority packets are more likely to get from server to client/client to server


EDIT: Or it just might be that the way i'm sending/recieving my packets is not the greatest way performance wise and too many are being dropped..

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 23rd Jun 2009 12:41
If you use UDP mode 'per client' (1) or 'per client, per operation' (2) then lots of packets will be dropped. If you use UDP mode 'catch all' (3) then none will be dropped by DarkNet, only those that didn't physically arrive will be lost.

kklouzal
15
Years of Service
User Offline
Joined: 15th May 2009
Location: Arizona
Posted: 23rd Jun 2009 13:02 Edited at: 23rd Jun 2009 13:05
I will definatly check out mode 3, just worried about old packets arriving after new ones.

EDIT: because, I don't know how, when I run my client & server program, which is on the same machine, I get a fair amount of "lag", it's more than likely my constant stream of udp packets being sent (guess it's time to figure out how to implement 'dead reckoning')

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 23rd Jun 2009 13:36
You can improve performance by using mnSetFunction. This allows you to specify your own function to be executed every time a new packet is received. This is much faster than using the mnRecv packet queue system.

kklouzal
15
Years of Service
User Offline
Joined: 15th May 2009
Location: Arizona
Posted: 23rd Jun 2009 23:16 Edited at: 24th Jun 2009 00:52
!!!!!!!!!!!!! <3


EDIT: the documentation does not cover mnsetfunction well at all.
EDIT: EDIT: a quick example would be greatly appreciated

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 24th Jun 2009 01:25 Edited at: 24th Jun 2009 01:27
Quote: "EDIT: the documentation does not cover mnsetfunction well at all."

I think its pretty good, the mnSetFunction help file is attached for those who don't own DarkNet.

Perhaps an example would help:

Server


Client


There appears to be a bug with mnSetFunction, which is that the iClientFrom parameter of the packet passed to the UDP function is always 0 in server state UDP mode 3 (catch all).

After going over DarkNet code rewriting large parts of it to make it more manageable and improve performance, I had already fixed this for the next version.

Attachments

Login to view attachments
kklouzal
15
Years of Service
User Offline
Joined: 15th May 2009
Location: Arizona
Posted: 24th Jun 2009 03:09 Edited at: 24th Jun 2009 10:30
Ah there we go! that's what i needed

EDIT: i can still let tcp packets be handled by the queue system yes? (dosent matter cause ill use the mnsetfunction for both)

EDIT: EDIT: The transition to mnSetFunction is rough but needed xD (first compile try got 86 errors )

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 24th Jun 2009 10:52
Quote: "EDIT: i can still let tcp packets be handled by the queue system yes?"

To do this, just set the TCP function parameter to 0, and the queue system will be used for TCP.

Kylontario
15
Years of Service
User Offline
Joined: 7th Jul 2009
Location:
Posted: 14th Jul 2009 02:45
Quote: "just worried about old packets arriving after new ones."

Just set an ID number to each update, and a counter to the recipient machine. When the recipient gets an update, it first checks that the ID is higher than it's counter, and if it is, then store the new higher number and proceed with the update. If not, then simply reject it. This way, any late arrivals won't cause the game to go "back in time".

I know the counter would eventually exhaust, so when the number can't count any higher, the next update would have a reset command (like maybe -1 ID or something) that tells the counter to reset and continue. That way you can go indefinitely.

Hope this helps!
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 14th Jul 2009 11:36
Quote: "Just set an ID number to each update, and a counter to the recipient machine. When the recipient gets an update, it first checks that the ID is higher than it's counter, and if it is, then store the new higher number and proceed with the update. If not, then simply reject it. This way, any late arrivals won't cause the game to go "back in time"."

That is pretty much how the new UDP mode works.

Quote: "I know the counter would eventually exhaust, so when the number can't count any higher, the next update would have a reset command (like maybe -1 ID or something) that tells the counter to reset and continue. That way you can go indefinitely."

When the maximum is reached and the counter tries to increase, it will simply loop back to 0. At this point the difference between the last counter and the current counter will be unusually large and so it can be assumed that the counter has looped round. That is how DarkNet knows when to reset.


This Friday (hopefully) I will release the next version of DarkNet, which includes this new UDP mode.

Kylontario
15
Years of Service
User Offline
Joined: 7th Jul 2009
Location:
Posted: 14th Jul 2009 21:41
Oh, it already does that stuff for you? Guess that saves me a lot of trouble. I honestly would have done that myself.
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 27th Aug 2009 14:00 Edited at: 27th Aug 2009 14:06
DarkNet website
There is now a website for DarkNet which is aimed at those considering whether or not to purchase DarkNet.

This website can be found at:
http://www.DarkNetworking.net

v1.1.6
v1.1.6 has recently become available and you can download it in your order history.

For more information on the latest version of DarkNet watch out for an article in the September TGC newsletter.

Moving from v1.1.4 to v1.1.6
This is relatively straightforward. By default, everything is the same as it was in v1.1.4 e.g. graceful disconnect is disabled.

You only have to worry about the following:
-mnGetTCPRecvSize has been renamed mnGetTCPRecvSizeA.
-mnGetErrorCode now returns long long int instead of int.
-mnGetErrorMode now takes an error mode parameter and is used to determine whether an error mode is on or off.
-mnConnect and mnPollConnect can now return -2 indicating that the server rejected the connection request. This normally means the server is full.
-mnSetFunction, the thread ID of function parameters is no longer passed by reference.

General
DarkNet has been optimised and restructured. There isn't much that hasn't improved in efficiency, so you should notice some kind of performance increase.

The documentation has been completely rewritten and is much more useful and easy to use.

The demo code has been updated and now includes 16 demo projects written in C++, DBP, C# and VB.NET.

There are also several bugs that have been fixed:
- Packet commands may not always display correct error message when there is not enough memory in packet to add or get data.
- Packets may not always have variables such as client ID set properly.
- Server/clients could not continue to transfer data in UDP mode 2 and 1 after 49.7 days of being connected.
- Vulnerability where certain situations could cause the server to display an error message or be unable to receive UDP data.
- mnFinish would not re-enable UDP on the specified instance.
- mnToggleAffinity, mnGetAffinity, mnSetAffinity, mnGetPriority and mnSetPriority were not working.

Improved Error System
You can now have more than one error mode enabled at the same time using mnToggleErrorMode. mnGetErrorMode has changed as a result.

Save error mode has improved so that you don't have to check the return values of commands to determine if an error has occurred. Instead you can use mnGetErrorFlag to determine when an error has occurred. You can use mnSetErrorFlag and mnClearErrorFlag to toggle error state and control what mnGetErrorFlag returns.

A clError (C++) and mnError (.NET) exception class now exists. When exception error mode (new) is enabled DarkNet functions will throw an exception of this type when an error occurs. The exception class is used internally to DarkNet; you now have the option to integrate your applications with the same error system that DarkNet uses. The documentation explains how to do this.

mnGetErrorMode now takes an error mode parameter and is used to determine whether an error mode is on or off.

There is demo code showing how to use the new error system.

Command list:


Packet Commands
Several new commands exist which make DarkNet packets more useful and dynamic.

mnErase can be used to erase a portion of the packet whilst mnInsert can be used to insert space into the packet, which can then be filled with an mnAdd command (e.g. mnAddInt).

A new command mnCreatePacketFromPacket exists which is faster than mnCreatePacket + mnEqualPacket. It has the same result as using those two commands.

There are several new string commands which operate similarly to their packet counterpart: mnCreatePacketFromString, mnComparePacketString, mnEqualPacketString.

mnChangeMemorySize can be used to change the memory size of a packet without wiping its contents (mnSetMemorySize wipes the contents of the packet).

mnAddMemblock and mnGetMemblock have been added for DBP users so that memblocks can be used with packets.

mnEncrypt now allocates new memory if not enough is available.

Command list:


Networking Commands
Several new networking commands have been added.

mnFlushRecvUDP and mnFlushRecvTCP can be used to empty the packet queue whilst mnGetTCPStoreAmount and mnGetUDPStoreAmount can be used to determine the number of packets in the queue. Note: packet queue refers to the queue of packets waiting to be received via mnRecvUDP or mnRecvTCP.

mnChangeBufferSizeTCP can be used to change the maximum possible size of an incoming TCP packet whilst the instance is active. This operates on a per client basis. mnGetTCPRecvSizeB exists to retrieve buffer sizes on a per client basis.

mnSetAutoResizeTCP can be used to set no limit on the maximum possible size of incoming TCP packet. The buffer size will increase as necessary. This operates on a per client basis.

mnGetTCPBytes is similar to mnGetTCPPercent except it retrieves the number of bytes worth of partial data (data that does not make up a complete packet).

mnDisableTCPHandshake can be used to disable the TCP handshake process. When this process is disabled DarkNet can communicate with applications not written with DarkNet. mnGetTCPHandshakeEnabled exists to check whether TCP handshake has been disabled.

mnSetTCPMode can be used to change the TCP mode to the new postfix mode which adds specified bytes of data to the end of each packet, and checks for these bytes at the end of incoming data to determine when a complete packet has been received. mnGetTCPMode exists to determine the TCP mode.

mnSetTCPPostfix can be used to set the postfix used with the postfix TCP mode. mnGetTCPPostfix exists to determine what the postfix is.

mnSetTCPMode and mnDisableTCPHandshake make communication via HTTP possible. Demo code exists to demonstrate this.

Graceful disconnecting is now possible using mnShutdownClient, mnEnableGracefulDisconnect and mnGetGracefulDisconnectEnabled. This allows clients to disconnect but data transfer to complete successfully.

mnSetSendTimeout and mnGetSendTimeout exist to protect the server from malicious clients. After the send timeout expires, if a packet has not been sent the client is forcefully dropped. This prevents blocking send operations from blocking permanently.

There is a new UDP mode (4) UM_CATCH_ALL_NO, UDP mode catch all, no out of order which is used in exactly the same way as UDP mode catch all but out of order packets are discarded.

All UDP modes now have procedures to ensure that data transfer can continue forever. Previously UDP modes 1 (per client) and 2 (per client, per operation) would stop working if a client did not disconnect after roughly 49.7 days.

mnDisableNagle and mnGetNagleEnabled can be used to disable the Nagle Algorithm which may improve TCP performance for some applications.

mnConnect and mnPollConnect can now return -2 indicating that the server rejected the connection request. This normally means the server is full.

Command list:


Firewall Commands
Roughly 90 new firewall commands have been added which allow full control over windows firewall.

Command list:


Sound Input/Output Commands
Roughly 50 new sound input/output commands have been added which allow sound data to be input, sent and played. This facilitates voice communication.

Command list:


Timidon
19
Years of Service
User Offline
Joined: 26th Jun 2005
Location: Bakersfield, Ca. USA.
Posted: 8th Sep 2009 08:25
I just picked up Darknet, tried to compile the Advanced Cube World code.

Got this error:


I did a quick search about that atls.lib, seams to be a piece of legacy code that is getting stuck. The help I found was suggested that I should tell the compiler to ignore this library, so I added that to the The Pro CW Project Page -> Configuration Properties -> Linker ->Input -> Ignore Specific Library -> atls.lib

I got this error after trying to rebuild.


So anybody else got this error? I am running MS Visual C version 9.

I should note that I was able to compile the "Server" example with no errors.

There are many answers but just one question" ~ Jerilith the Mad
Timidon
19
Years of Service
User Offline
Joined: 26th Jun 2005
Location: Bakersfield, Ca. USA.
Posted: 8th Sep 2009 08:55
Just Found the answer to the atls.lib error, I examined the Server project and found these libraries ignored "libcmtd, msvcrt, atls" (not including the .lib at the end, that works). I copied these over to the Pro Cube config and recompiled and got no errors. So just a reminder, add these to the list of libraries you should avoid.

Later. off Going to go play with my new code.

There are many answers but just one question" ~ Jerilith the Mad
entomophobiac
21
Years of Service
User Offline
Joined: 1st Nov 2002
Location: United States
Posted: 23rd Sep 2009 10:42
Great to see the NAT punch-through example! Something I've been eagerly awaiting.
OldPMan
TGC Store Seller
16
Years of Service
User Offline
Joined: 10th Aug 2008
Location:
Posted: 6th Dec 2009 19:06 Edited at: 6th Dec 2009 19:44
a question ...
the effect on the darknet SCREEN FPS ()
I noticed the impact.

transmission packet does not affect the speed, impact inaction.
I personally, if I have:
if TcpPacket> 0
then 60fps
else
then 40fps or 30fps
WHY ?????????????????
endquestion




edit\\
I use:
Dark Data
DarkNet
Styx
Dark Shader
BlueGUI
EZrotate Enhanced
DarkBASIC Professional Enhancements Expansion Pack
Dark AI
Dark Physics
Dark Lights
Can any one of these plugins to influence the work DARKNET?

.....already beside..... for all
Hatzl
14
Years of Service
User Offline
Joined: 9th Jan 2010
Location:
Posted: 9th Jan 2010 16:44
Hello,

I'm new in this Forum and I have a question.
Is one here, who can speak german and can Darkgdk with Darknet.?
I have purchased DarkNet but cannot write anything, because i didn understand the system...

Sorry for my bad english...

MFG Hatzl
pepebotellas
14
Years of Service
User Offline
Joined: 22nd Jan 2010
Location:
Posted: 26th Jan 2010 18:15
Question:

I noticed that Connect is a non blocking call. meaning that I can do other stuff while I connect.

How about Listening, Sending and receiving packets? Are they non-blocking as well? Couldn't find anything on the Documentation

I am interested in this product and I would like to know this information before making my decision.
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 26th Jan 2010 19:40
mnRecvUDP and TCP just check if any packets have been received recently and always return without waiting for a packet to be received.

mnSendUDP and TCP have a parameter that specified whether the command should block while the packet is sent. There isn't currently a way to poll on the status of the send operation so if you specify that the command should return instantly you cannot later determine if that packet was successfully sent.

mnPollConnect and mnStopConnect can be used to manage the handshaking process started by mnConnect if it is non blocking.

Basically all commands that may not return quickly have a boolean parameter that specifies whether or not the command should return instantly.

Login to post a reply

Server time is: 2024-10-01 23:43:19
Your offset time is: 2024-10-01 23:43:19