Version 2.0.1
Hi all,
Today v2.0.1 is completed and should be available to download via your TGC account on Tuesday or Wednesday.
You can view the updated documentation
here.
The following bugs have been fixed:
- Retrieving empty strings from packets in DBP will no longer cause an error.
- Broadcasting now works with the following code:
mn start 2,0
` Broadcast IP tells router to send message to all clients on LAN.
broadcastIP$ = "255.255.255.255"
` Local address that we are sending from.
IP$ = ""
port = 24000
` Bind to local IP, but retrieve a random port.
profileSend = mn create instance profile()
mn set profile local profileSend,IP$,0,IP$,0
` Bind to local IP and port so that we can retrieve data broadcast to that port.
profileRecv = mn create instance profile()
mn set profile local profileRecv,IP$,port,IP$,port
` Setup two instances, one for broadcasting and one for receiving broadcasts.
` Currently this is a bit buggy, both send and receive are enabled for both instances
` (parameters are ignored), and the instance profiles are not accessed, the connectToIP
` and connectToPort are the local IP and port used (contrary to what the documentation says).
` This will be changed so that instance profiles effect local bindings in the next update.
#constant BROADCAST_SEND_INSTANCE = 0
#constant BROADCAST_RECV_INSTANCE = 1
mn start broadcast BROADCAST_SEND_INSTANCE,broadcastIP$,port,1,0,profileSend
mn start broadcast BROADCAST_RECV_INSTANCE,IP$,0,0,1,profileRecv
sendFreq = 1000
sendTimer = 0
sendPacket = mn create packet()
myUniqueString$ = get time$()
mn add string sendPacket, myUniqueString$,0,1
recvPacket = mn create packet()
do
sync sleep 1
if timer() - sendTimer >= sendFreq
mn send udp BROADCAST_SEND_INSTANCE,sendPacket,0,1,0
sendTimer = timer()
print "Sent broadcast packet"
endif
recvAmount = mn recv udp(BROADCAST_RECV_INSTANCE,recvPacket,0,0)
if recvAmount > 0
print "Received broadcast packet: " + mn get string(recvPacket,0,1)
endif
loop
Note that a single broadcast instance cannot send and receive at the same time, so you do need to make separate broadcast instances for sending and receiving.
Security
DarkNet is now 100% secure in the sense that there is no way to crash a server or client so long as memory limits are low enough to prevent the application from running out of memory. Ofcourse DarkNet cannot account for any code you've written yourself, but DarkNet itself is secure.
By default there are no memory limits, but you can use
mnSetProfileSendMemoryLimit and
mnSetProfileRecvMemoryLimit to change these. All memory limits apply to an individual client (i.e. each clients memory usage is logged individually) except UDP sending, which applies to the entire instance.
The memory usage of a client can be retrieved using
mnGetRecvMemorySizeUDP,
mnGetRecvMemorySizeTCP and
mnGetSendMemorySizeTCP. Before a client is allowed to exceed its memory limit it is silently disconnected.
Memory Recycling
This is explained nicely in a previous post. I will now detail the specifics on how you use this system and what its impact is.
Memory recycling allows you to trade space efficiency for processing efficiency. There are two key options which decide how significant the trade is: 'number of recycle packets' and 'memory size of packets'. These are configured by
mnSetProfileMemoryRecycleTCP and
mnSetProfileMemoryRecycleUDP.
The number of recycle packets is the number of packets that can be in the 'recycle bin' at any one time. At startup the recycle bin is populated with this number of packets. The recycle bin may decrease in size as packets are taken out and used, but will never exceed this size. Packets in the recycle bin are always of size 'memory size of packets'. Therefore the maximum size that the recycle bin can be is: number of packets * memory size of packets. This is the approximate loss in space as a result of using the recycle bin.
The gains from using memory recycling depend on how many needless deallocations are prevented. Memory recycling will prevent needless deallocations so long as:
- The number of packets in the queue waiting to be received via mnRecvTCP or mnRecvUDP is less than the number of packets which can be stored in the memory recycle bin. If this is not the case, for every extra packet that goes over the limit an allocation and deallocation will occur.
- The memory size of packets received and packets sent asynchronously do not exceed the size of packets in the memory recycle bin. For every packet that does an allocation and deallocation will occur. This limit is useful if e.g. you send a large map file to clients when they join, there's not much point recycling a huge packet because the space trade is not worth the small increase in performance from this one off event.
Lastly, the memory recycle is taken into account in memory limits so everything is still secure.
Its important to note that the server will continue running as normal no matter what you set the parameters to, only efficiency will change.
This may be a bit confusing at first so feel free to ask questions.
[edit]
Due to a bug in VS the C++ VS2008 debug version of DarkNet wouldn't compile, but you can still use the release version and either version of VS 2010.
