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.

Program Announcements / MikeNet - Multiplayer Plugin

Author
Message
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 12th Jan 2009 11:16 Edited at: 12th Jan 2009 11:17
Quote: "Of course, this is only true for UDP."

It is true for TCP as well, when using mnStartServer or mnConnect with a local IP and port that is already in use an error will occur with an error code of 10048. However, you can have UDP and TCP bound to the same local IP/port.
kaedroho
16
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 13th Jan 2009 18:46
It all works now, Thanks for your help!

GIDustin
15
Years of Service
User Offline
Joined: 30th May 2008
Location:
Posted: 14th Jan 2009 02:04
Quick request if you could humor me. Could you add the ability to forward packets?

For instance, client A sends a packet. The host gets it, and checks the operation. If its a certain operation, I can forward that packet to all the other clients. I haven't yet tried the following:



I am not sure if you allowed people to take the Receiving packet and send that, but I figure since I already did an mn Get Int() for the Operation, that the operation might be missing from the packet.

Hopefully you understand all that, I am a little sick and on some meds. I probably shouldn't be coding...

Also, been loving the LAN support.
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 14th Jan 2009 08:45 Edited at: 14th Jan 2009 08:46
You can already do this . When you use an mnGet command on a packet, the data that is returned is not removed from the packet. All that happens is the packet's cursor moves along; the cursor is just an integer that indicates where the next mnGet command should start from.

When sending, the packet up to its used size is sent regardless of where the cursor is. The used size indicates how much of the packet is filled with data.

If you have problems with this please let me know. Get well soon!
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 14th Jan 2009 17:53
Quote: "It is true for TCP as well"

It's not, it's just that by default you can't bind multiple sockets to the same protocol/ip/port if they haven't be bound using the SO_REUSEADDR option. Use this, and you can bind multiple TCP sockets to the same port, but the destination IP or port must be different (a TCP socket is unique by its local ip/local port/remote ip/remote port).

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 14th Jan 2009 18:12 Edited at: 14th Jan 2009 23:52
Quote: "It's not, it's just that by default you can't bind multiple sockets to the same protocol/ip/port if they haven't be bound using the SO_REUSEADDR option. Use this, and you can bind multiple TCP sockets to the same port, but the destination IP or port must be different (a TCP socket is unique by its local ip/local port/remote ip/remote port)."

I did not know this ; thanks for the information.

I was wondering if you could answer: Are there any disadvantages of enabling SO_REUSEADDR on a TCP socket to be used with WSAConnect?
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 15th Jan 2009 01:08
Quote: "I did not know this ; thanks for the information."

You're welcome.

Quote: "Are there any disadvantages of enabling SO_REUSEADDR on a TCP socket to be used with WSAConnect? "

Not that I'm aware of, but then I can't see any advantages either unless you need to explicitly bind to a specific port (which under most cases you don't).

KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 15th Jan 2009 21:04 Edited at: 15th Jan 2009 22:52
I'm having trouble with the encryption.

Both the server and the client crash hard (no DBPro or MikeNet errors shown)

The client crashes when it tries to encrypt the packet.


The last thing I see on screen is the key, which is a Double Int.

The server crashes at the same time, but I don't yet know why. According to similar print statements used for debugging, it never receives the packet.

[edit] I think I know why the server is crashing. Although I can't really explain it. In the main loop I'm assuming that you have to check for a packet from each connected player. So inside a for next loop I first check for a TCP packet

then check for a UDP packet

and continue looping through each connected player.

I commented out the UDP section and the initial crash that was happening stopped.

Can you have a server hosting TCP and UDP on the same port on the same IP? I thought this was ok, but maybe not.

Basically what I've done is gone through my entire project server and client and replaced all Multisync commands with MikeNet commands. MikeNet seems to be a bit more picky so far, but the performance gains with UDP and having encryption are very enticing.

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 15th Jan 2009 21:49 Edited at: 15th Jan 2009 23:58
I'm not sure what the problem is, but I do not think it is a problem with MikeNet. I ran the following test code which worked fine:

Client:


Server:



Also regarding the code snippet you posted, there are some things that you may find useful to know (if you don't already):

1. The two lines below do the same thing. If the length parameter of mnAddString is 0, MikeNet will work out the length for you:


2. When using mnGetByte, you must first store it in a variable before passing it to a function as I have done in the test code; this is a problem with DBP. [edit] This is actually an issue with MikeNet that will be fixed for the next version.

3. The variable in the below line does not hold a representation of the key (i.e it is completely unrelated to the key parameters). It now contains a memory address to the location of the key data.



Please let me know how you get on regarding this problem. Hope I helped
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 15th Jan 2009 22:02
Ok, I'll go back through the code and check on those things. I was using the Players(me).key variable to store the key itself, so that would explain that issue.

I did run into the issue with Bytes. It seems MikeNet treats them differently then Multisync. Not sure how Ben worked that out.

Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 15th Jan 2009 22:51
Quote: "2. When using mnGetByte, you must first store it in a variable before passing it to a function as I have done in the test code; this is a problem with DBP."

I've (fortunately) not encountered such a problem, I always use the D parameter in the string table, and have the function accept a DWORD.

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 15th Jan 2009 23:52
mnGetByte returns unsigned char instead of DWORD, that is the problem. I always assumed it was DBP's fault, silly me ; I'll fix this for the next version.
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 16th Jan 2009 00:14
I'm curious, if the last 2 parameters for

mn Add String packet, string, length, null

aren't really needed, why have them?

Anyway, still debugging. Haven't attempted encryption yet, as I'm trying to get the server and client up and running back to where it was with MultiSync, then I'll enable the encryption code.

MikeNet seems to crash to a "Please allow us to send all this information to Microsoft that they'll never look at." box rather easily. I haven't yet seen an error message box from MikeNet. Any ideas why that might be?

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 16th Jan 2009 08:45 Edited at: 16th Jan 2009 16:57
Quote: "mn Add String packet, string, length, null"

The last two parameters are for C++ mainly, but I thought they might have some use in DBP. They allow you to use character arrays that aren't null terminated.

Quote: "MikeNet seems to crash to a "Please allow us to send all this information to Microsoft that they'll never look at." box rather easily"

I did try and catch all possible errors, I guess I missed some. If you can tell me what you did to crash MikeNet then I can add in protection against it. Just in case, make sure you haven't used mn disable message boxes without enabling it again.

[edit] I have decided to rewrite the error system for the next version so that crashes with or without an error should not occur as a result of MikeNet.
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 16th Jan 2009 18:50
I checked on the mn Disable Message Boxes to be sure, and I didn't put it anywhere in the server, and I'm removing it from the client. I'll let you know if I see anything different.

Quote: "If you can tell me what you did to crash MikeNet then I can add in protection against it."


I wish I knew. The two things that stand out are mn Recv UDP crashes on the server, and something is crashing it right after the client leaves. Still tracking down exactly what command it is. It's nearly 5,000 lines in the server, and 7,000 in the client.

Just to let you know, before I started converting this 12,000 line project to MikeNet, I had already converted the Online File Update app, and it works great. A bit slower than the DBPro FTP commands, but it seems to be much more reliable.

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 16th Jan 2009 20:45 Edited at: 16th Jan 2009 20:46
Quote: "I wish I knew. The two things that stand out are mn Recv UDP crashes on the server, and something is crashing it right after the client leaves. Still tracking down exactly what command it is. It's nearly 5,000 lines in the server, and 7,000 in the client. "

If you know what section is causing the problem, you could post or email the section to me. I might be able to spot what is wrong.

Quote: "Just to let you know, before I started converting this 12,000 line project to MikeNet, I had already converted the Online File Update app, and it works great. A bit slower than the DBPro FTP commands, but it seems to be much more reliable."

Nice . This might help speed things up if you didn't already know: In DBP, there is a pretty big overhead with putting the files into packets because (so far as I know) each byte has to be added individually. The overhead also applies to C++ but not to the same extent because mnAddStringC is a much faster way of adding an array of data. So it is faster to load all the files into packets on start up, and then send them when necessary.
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 16th Jan 2009 21:04 Edited at: 16th Jan 2009 21:27
I don't think I actually calculated the transfer rate, but in looking at my network usage during a large file transfer I was getting about 2 mbit/s on a 100 mbit network. Not to shabby. I suspect it will be fast enough for what I'm doing. That also keeps file downloads from sucking up all my bandwidth, and interfering with the game.

What I've found so far is not only do you have to use a variable set as type byte to send one with mn Add Byte, but mn Get Byte wont put it's value into anything but a byte type variable. I don't necessarily consider this a bad thing, it's just exposing my poor variable management skills..

Once I cleared this up, the data I was expecting started to come through fine, and right up until the client disconnects, the server has stopped crashing. (except for receiving UDP packets.)

Once the client connects, as soon as I check for any incoming UDP packets, I get a crash.

If I comment out the bit between the --> then it doesn't crash.

Here's the code I'm using for when the client disconnects or drops.

It crashes on the first line for some reason.

Here's my server startup settings.

and the Client startup settings.


Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 17th Jan 2009 01:10 Edited at: 17th Jan 2009 01:10
I ran some tests and found a couple of issues with UDP which I will fix for the next version:

1. The problem you are experiencing with mnRecvUDP appears to be an issue with MikeNet in UDP mode per client.
2. In UDP mode per client per operation, an error will incorrectly appear telling you that an invalid operation ID has been used if an operation that is not 0 is used.

I aim to release the next version (including .Net) for next weekend, 24th/25th.
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 17th Jan 2009 02:06
Quote: "2. In UDP mode per client per operation, an error will incorrectly appear telling you that an invalid operation ID has been used if an operation that is not 0 is used."


I assume you mean Per Client mode. Although the operation id I've been using is 0.

Quote: "I aim to release the next version (including .Net) for next weekend, 24th/25th. "


I will wait semi-patiently and maintain my game across both the Multisync and MikeNet copies until then..

Any idea why mn Client Left(Server) is crashing on me? It works fine in the file update app, but for some reason it doesn't like it in the game. I've been looking over the code for hours and can't find any reason why..

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 17th Jan 2009 18:00 Edited at: 17th Jan 2009 18:01
I'm not sure what could be causing the crash with mnClientLeft. It is unlikely to be MikeNet because mnClientLeft is relatively simple, and I see no problems with it; I will run some tests to make sure though.

I'm sorry for the delay, unfortunately I have a particularly busy couple of weeks coming up.

In the next version there will be:
-Bug fixes
-Far greater stability. It should be almost impossible to crash MikeNet, even if you use commands incorrectly.
-Greater control over error message boxes, it will be possible to disable all error message boxes except those from within the worker threads.
-.Net compatibility
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 17th Jan 2009 18:57
@ KISTech
Good news! I have a simple work around for your problem with mnRecvUDP. Set the maximum number of operations to 1 with mnStartServer and the problem should be solved
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 18th Jan 2009 01:07
Hmm, not only did that fix the UDP recevie problem, but that seems to have fixed the Client Left problem too. All is right with the world again. (well, the real one anyway..)

Hopefully that will give you a little insight into the deeper issue that caused the crash.

Thanks.

dale2507
15
Years of Service
User Offline
Joined: 1st Apr 2008
Location: My own little world...
Posted: 19th Jan 2009 20:43
Hey i've had an idea. Don't know if it's possible though. Could you put UPnP or something similar into mikenet so that it can automatically forward ports from your router? I'm sure all those gamers out there would really love to see a game that you don't need to go into your router settings for.
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 19th Jan 2009 22:02
@ KISTech
The crash that occurs when clients leave is related to the mnRecvUDP problem, and both have been fixed for the next version so that the maximum number of operations being set to 0 does not cause crashes.

@ dale2507
Normally port forwarding is only necessary when hosting a server. However, I think what you are asking for is possible and so I will have a deeper look into it, although I probably won't have time to implement it for the next version.
dale2507
15
Years of Service
User Offline
Joined: 1st Apr 2008
Location: My own little world...
Posted: 19th Jan 2009 22:34
Awesome i look forward to it!!

Thanks for the reply an the awesome plugin!!
AlexI
19
Years of Service
User Offline
Joined: 31st Dec 2004
Location: UK
Posted: 20th Jan 2009 01:36
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 20th Jan 2009 05:33
I've only had one other issue over the weekend, and that had to do with an error saying that it was an invalid client number, but I've checked all the code and it's correct. The weird part is it says the error is on a line that only contains an endif, and there's no MikeNet code anywhere near it. The error code was 997.

Other then that, everything seems to be running, and because I'm able to use UDP to send client and NPC movement updates, it performs a bit faster. Hopefully that will still be the case when I turn on encryption.

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 20th Jan 2009 08:27 Edited at: 20th Jan 2009 08:30
Quote: "I've only had one other issue over the weekend, and that had to do with an error saying that it was an invalid client number, but I've checked all the code and it's correct. The weird part is it says the error is on a line that only contains an endif, and there's no MikeNet code anywhere near it. The error code was 997.

Other then that, everything seems to be running, and because I'm able to use UDP to send client and NPC movement updates, it performs a bit faster. Hopefully that will still be the case when I turn on encryption. "

The line number refers to the line within MikeNet, not your code. If you see the error again then please tell me the line number and I should be able to track down what MikeNet command caused the error .
Alfa x
17
Years of Service
User Offline
Joined: 1st Jul 2006
Location: Colombia
Posted: 20th Jan 2009 13:27
Quote: "In the next version there will be:
-Bug fixes
-Far greater stability. It should be almost impossible to crash MikeNet, even if you use commands incorrectly.
-Greater control over error message boxes, it will be possible to disable all error message boxes except those from within the worker threads.
-.Net compatibility"


Quote: "I may add an option to set affinity of threads in the next version."


Can you do this please? .
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 20th Jan 2009 13:57
Yes, I'll be implementing that today, sorry for missing it out
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 20th Jan 2009 17:29
It was line # 4299.

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 20th Jan 2009 18:16
The error occurred when a UDP packet was received by the client, and the packet had an invalid client ID. This would suggest that the packet you are sending from the server is not correct for the UDP mode that you are using. I wrote a fairly detailed section explaining the UDP modes in the file "MikeNet General Information" included with the download zip which explains how to use them.
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 20th Jan 2009 19:17
So if I'm reading this correctly, for every packet that I send from the server I have to have this as the first insertion into the packet?

mn Add Int {Packet Name}, {Client ID this packet is about}

and on the client end MikeNet picks this off and stores it for packet management purposes?

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 20th Jan 2009 19:21 Edited at: 20th Jan 2009 19:21
Quote: "So if I'm reading this correctly, for every packet that I send from the server I have to have this as the first insertion into the packet?

mn Add Int {Packet Name}, {Client ID this packet is about}

and on the client end MikeNet picks this off and stores it for packet management purposes?"


Yes, in the UDP mode "per client".
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 20th Jan 2009 19:32
Interesting. So if this value allows the client to store a packet for each possible client, does that mean the UDP receive buffer needs to be large enough to handle (packet size * max players)?

Which in my case would be 2048 * 200 = 409,600

That's a very nifty way of handling UDP packets and storing the latest data for the clients. It does present a small problem with NPCs though, since they don't have a client ID they get to share only 1 UDP packet slot. Might have to rely on a hybrid system of making sure the NPC data gets through when it's needed. Maybe UDP updates when they are X distance away, and TCP updates when they are closer.

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 20th Jan 2009 19:41
Quote: "So if this value allows the client to store a packet for each possible client, does that mean the UDP receive buffer needs to be large enough to handle (packet size * max players)?"

MikeNet creates as many buffers as needed, of the UDP receive buffer size. So you should set the UDP receive buffer size to be equal to or greater than the size of the largest individual packet that could be received.

Quote: " It does present a small problem with NPCs though, since they don't have a client ID they get to share only 1 UDP packet slot."

You might want to look at the other UDP modes. "Per client, per operation" was designed to get around this sort of problem: each client has more than one packet slot and the operation ID is used to differentiate between each slot. You could also use "UDP catch all" mode which hands you total control and is similar to TCP in terms of usage.

There is a bug in the current version with "Per client, per operation" where you can only use operation 0. This is a silly mistake in code designed to stop bad operation IDs being used. This will of course be fixed for the next version .
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 20th Jan 2009 19:48
Quote: "MikeNet creates as many buffers as needed, of the UDP receive buffer size. "


Ah, I see. That helps.

Quote: "You might want to look at the other UDP modes. "Per client, per operation" was designed to get around this sort of problem:"


I was starting to let my mind wander in that direction. I don't think the Catch All mode would be quite as fast, since I would have to manage the packets myself in DBP code, which would be slower then letting MikeNet do it.

I may just have to switch to Per Client Per Operation mode. That sounds like a lot of flexibility that I can get myself in trouble with.

dale2507
15
Years of Service
User Offline
Joined: 1st Apr 2008
Location: My own little world...
Posted: 22nd Jan 2009 20:04
Hello again!

just a quick question. Can mn send tcp all be used in a client state to just send data to the server since that's the only question? the reason i ask is we're currently working on a first person shooter incorporating a server and client into one and it get a bit annoying having to find out weather the game is currently a server and has to send data to everyone or a client and only have to send it to the server.

Thanks in advance!!

btw we're hoping to have some screenies and possibly an alpha version out soon which we'll post just to show how amazing mikenet is so keep a lookout for Fighting for Freedom by Silenced Studios
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 22nd Jan 2009 20:36
@ dale2507
Currently you can't do that. However, you could create your own function which has the same parameters as mnSendAll and if in client state uses mnSend and if in server state uses mnSendAll. That way you wouldn't have to keep switching between the two in your code.

I'll be looking out for your game, good luck
dale2507
15
Years of Service
User Offline
Joined: 1st Apr 2008
Location: My own little world...
Posted: 22nd Jan 2009 20:44
Thanks din't think of that lol. Working on it with Tv-XxX just so u know.

Would it be possible for you to give an example of using more than 1 operation in per client, per operation mode? i had a go as we could do to use udp for movement and bullet data but can't figure how to do it. don't know if it's something to do with the version of mikenet we're using but i got an operation error. Mikenet v1.0.9 i believe. looking to upgrade on next release.
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 22nd Jan 2009 20:51 Edited at: 22nd Jan 2009 20:53
That is a bug which means you can only use operation number 0. It will be fixed in the next version which I plan to release this weekend. The cube world demos are in "per client, per operation" mode although they only use operation number 0.

[edit]
Forgot to mention: upgrading from 1.0.9 to v1.1.0 doesn't require any major changes, so it won't be very difficult
dale2507
15
Years of Service
User Offline
Joined: 1st Apr 2008
Location: My own little world...
Posted: 22nd Jan 2009 21:01
Yer i saw your post saying that the packets were the last major change. Tv-XxX has his reservations after reading number of problems people had. i'm sure we'll survive for weekend an if u don't get it out i'll have a go at upgrading to latest see if i get any bugs.
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 23rd Jan 2009 19:40 Edited at: 23rd Jan 2009 19:42
@Michael

Just so you know, I've succeeded in converting all of the Worlds Apart Online code to MikeNet. The Online File Update program and the Server and Game applications now all use MikeNet exclusively.

I anxiously await the Per Client Per Operation fix so I can test that with the NPC movement updates. Right now Per Client mode is dropping packets faster then I can process them, so the vast majority of the NPC movements are missed. (which is of course to be expected when you're sending 50 updates at once from client 0 operation 0 every 2 seconds..)

I did actually consider using Catch-All, but I still think that would be to much overhead, and in times of high traffic DBP having to process all those packets would degrade performance.

I can't wait to see just how many players I can get on this thing at the same time.

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 23rd Jan 2009 19:48 Edited at: 23rd Jan 2009 19:56
Version 1.1.1
The next version has arrived, here are the key changes:

Error System
The error system in all previous versions was a little unstable. Crashes through miss-using MikeNet were not uncommon and consequently debugging was difficult, especially in DBP. In this version the error system has been rewritten so that it is much more difficult to crash MikeNet (near impossible).

In previous versions if an error occurred midway through a function the function would continue to execute until it reached the end. This meant that multiple error message boxes could be displayed, or the original error could cause a crash further down the line. In this version if an error occurs midway through a function the function exits.

In the event of an error that would normally cause a crash an error message will be displayed and no crash will occur.

The error message that is displayed now tells you what command caused the error. You can use mnGetErrorCommand to determine this when error message boxes are disabled:


Finally, you no longer have to use mnClearError (it has been removed).

Thread commands
You can now change the priority and affinity of MikeNet worker threads with mnToggleAffinity, mnSetAffinity, mnSetPriority, mnGetAffinity, mnGetPriority.

Packet manipulation commands
You can now add packets together, determine whether two packets are the same and copy the contents of one packet into another. The new commands for this are mnAddPacket, mnComparePacket and mnEqualPacket. C++ and .Net users can use the operators of the clPacket and Packet class.

.Net
MikeNet is now compatible with .Net and there is demo code for C# and VB .

Bug fixes
Three bugs have been fixed:
1. If maximum number of operations was not set to 1 with mnStartServer in "per client" UDP mode crashes would later occur. You can now set this value to anything in this mode.
2. In "per client, per operation" only an operation ID of 0 would be accepted. All operation ID should now work properly.
3. In DBP bytes are now returned properly so that they can be passed directly to a function without having to store them in a byte variable first.

Download
Version 1.1.1 (Mirror 1)
Version 1.1.1 (Mirror 2)

Attachments

Login to view attachments
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 23rd Jan 2009 20:06 Edited at: 23rd Jan 2009 20:14
I know this is a double post, but I feel the previous post should be dedicated to the new version.

@ KISTech
Quote: "Just so you know, I've succeeded in converting all of the Worlds Apart Online code to MikeNet. The Online File Update program and the Server and Game applications now all use MikeNet exclusively."

Excellent

Quote: "I did actually consider using Catch-All, but I still think that would be to much overhead, and in times of high traffic DBP having to process all those packets would degrade performance."

I agree, especially in DBP.


Hope you like the new version
dale2507
15
Years of Service
User Offline
Joined: 1st Apr 2008
Location: My own little world...
Posted: 23rd Jan 2009 20:25
wow! upgrading from v1.0.9 to v1.1.1 and didn't need to change a thing! nice work!

i'll give it a go at using more than one operation at some point tonight.
AlexI
19
Years of Service
User Offline
Joined: 31st Dec 2004
Location: UK
Posted: 23rd Jan 2009 21:38 Edited at: 23rd Jan 2009 21:40
Thanks will upgrade soon Will you look at adding UPnP support?

KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 23rd Jan 2009 22:17
Fantastic work !!!

It works like a charm, and none (or very little) of the NPC data is being dropped using Per Client Per Operation mode. Not only that but ping times have dropped from an average of 300-400 to less than 60, and I haven't even experimented with multiple threads yet.

I wasn't quite sure how fast DBP was going to handle running through a loop like this...



It seemed to do pretty well. From the server (ID = 0) I can now send independent updates for 1,000 entities with very few dropped packets and only need to check a few operations for all the other client IDs.

Thanks !!!

KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 23rd Jan 2009 23:57 Edited at: 24th Jan 2009 00:06
I thought I'd go ahead and enable encryption since everything is running so smoothly. However I ran into a strange problem.

I've tracked it down to when the client receives it's first encrypted UDP packet. TCP packets work fine, but the client drops the server connection as soon as it tries to receive an encrypted UDP packet.

Here's a question for you. Since the server is adding the client ID and the operation ID to the packet, and the client adds the operation ID to it's UDP packet, then encrypts the packet, is the encryption routine set up to NOT encrypt those elements before it sends the packet?

It's the only thing I can think of as to why the TCP packets work fine, but UDP has issues. I'm disabling encryption on UDP packets to test this theory. Be right back..

[edit]
Confirmed. I disabled encryption for UDP packets and it's working again.

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 24th Jan 2009 02:58
@ AlexI
Yes, that is my main focus for the next version

@KISTech
You are correct, the problem is that the UDP packets are not being decrypted by MikeNet and the entire contents of the packet is being encrypted. When receiving, MikeNet trys to read the encrypted contents and reads unusual values which result in an error message or the client being dropped.

You can get around this problem by using mnSetDecryptUDP to tell MikeNet to decrypt UDP packets with the specified key as they arrive.

Login to post a reply

Server time is: 2024-03-29 14:55:17
Your offset time is: 2024-03-29 14:55:17