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
kaedroho
13
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 10th Feb 2009 17:07
Alright, thanks.

Downloading.

kaedroho
13
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 10th Feb 2009 17:30 Edited at: 10th Feb 2009 17:44
It took me 4 connects/disconnects to crash it this time instead of 1.

The top error came up every time I disconnected and the bottom came up when I tried to connect for the 4th time but failed.

The server side is the exact same as last time. Except for every connect it said that a client connected and it didnt say when a client disconnected. Also every time I connected my client number was 1 higher than the last time I connected, so mikenet didnt detect a disconnect.

Attachments

Login to view attachments
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 10th Feb 2009 20:07
The results of this test don't indicate anything more than we already know.

It is strange that the server did not detect the disconnect; I have checked and the sockets are being closed properly by MikeNet which is supported by the _Finish message.

I think that it is reasonable to conclude that the reason for these problems is one of the following, most likely server related:
-Hardware problems (e.g. router)
-Software problems (e.g. firewall)
-Connection problems (e.g. internet connection)

I hope you can work out what is wrong, good luck
KISTech
13
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 10th Feb 2009 20:25
What's the operating system on the server?

Is the firewall on the server completely disabled? (relying on the firewall on the router of course..)

kaedroho
13
Years of Service
User Offline
Joined: 21st Aug 2007
Location: Oxford,UK
Posted: 10th Feb 2009 22:30 Edited at: 10th Feb 2009 22:35
The server is Windows Server 2003 x64.

Im not sure about the firewall. Ill find out for you.


Thank you very much for all of your help. Were going to try out a different server to see if it fixes anything. If it doesnt then I guess that ill be posting here again.

I will make sure that you are credited for your work on MikeNet and for all of your help that you have given us.

KISTech
13
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 11th Feb 2009 03:36
Make sure the firewall is off. I've used DBPro on Win2K3 Server, but not with MikeNet, so I don't know how that might play out.

Try it on an XP box.

AlexI
16
Years of Service
User Offline
Joined: 31st Dec 2004
Location: UK
Posted: 12th Feb 2009 15:50
Are you looking at adding UnPnP still?

Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 12th Feb 2009 17:59
Yes I have made a significant amount of progress so that I can now setup port forwarding using my UPnP code. Currently I am adding finishing touches and ensuring that it is easy to use.

In the next version there will be:
-Faster more efficient sending (done)
-UPnP NAT traversal (doing)

I'm not sure when this will be ready for release, it depends on how much time I have.
AlexI
16
Years of Service
User Offline
Joined: 31st Dec 2004
Location: UK
Posted: 13th Feb 2009 01:38
KISTech
13
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 13th Feb 2009 17:08
Quote: "In the next version there will be:
-Faster more efficient sending (done)"


Really? Outstanding!!

Before using MikeNet, I was getting 300-500 ms ping times in my game. Now I'm getting a consistent 50 ms.

Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 13th Feb 2009 17:16
Quote: "Really? Outstanding!!

Before using MikeNet, I was getting 300-500 ms ping times in my game. Now I'm getting a consistent 50 ms."

Here is a more detailed explanation:

Currently the data of a packet is copied once with every mnSend command, and is copied once per client sent to with mnSendAll. So, if I send to 5 clients the packet will be copied 5 times.

In the next version, the packet will not be copied at all in blocking sends, thus speeding up the process and lowering processor usage.

Most noticeable improvements will occur when sending to a large number of clients and when sending large packets.
AlexI
16
Years of Service
User Offline
Joined: 31st Dec 2004
Location: UK
Posted: 13th Feb 2009 18:56
KISTech
13
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 13th Feb 2009 20:07
Given the sheer volume of packets I'm sending, it should still speed things up a bit.

Virtual Nomad
Moderator
15
Years of Service
User Offline
Joined: 14th Dec 2005
Location: SF Bay Area, USA
Posted: 13th Feb 2009 23:11 Edited at: 13th Feb 2009 23:13
KISTech said:
Quote: "
Before using MikeNet, I was getting 300-500 ms ping times in my game. Now I'm getting a consistent 50 ms
"


i can personally vouch for that. while i don't use MikeNet as a programmer (i wouldn't know where to start ), i am enjoying the benefits as a player!

keep up the good work!

Virtual Nomad @ California, USA
AMD Phenomâ„¢ X4 9750 Quad-Core @ 2.4 GHz . 8 GB PC2-6400 RAM
ATI Radeon HD 3650 @ 512 MB . Vista Home Premium 64 Bit
prasoc
12
Years of Service
User Offline
Joined: 8th Oct 2008
Location:
Posted: 14th Feb 2009 00:54 Edited at: 14th Feb 2009 00:55
I have been having a problem lately, if a client connects over the internet, sometimes the server disconnects them (it says on the server itself) but they are receiving udp packets still, but not sending them, it is really strange. Great plugin though, works a treat apart from the weird bug
KISTech
13
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 14th Feb 2009 01:49
Sort of sounds like you aren't checking to see if the client is still connected in your code before sending them packets.



Of course this doesn't help with the SendToAll commands..

Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 14th Feb 2009 09:34
If a client is disconnected then further data transfer with that client should be impossible; mnSend won't send data to a disconnected client.

The server will disconnect a client if the client does something out of the ordinary. This could include:
-A wrongly formatted UDP packet (see "MikeNet General Information.doc" in the documentation folder for information about UDP modes).
-A TCP packet that is too large (use mnSetBufferSizes to increase maximum size).
-Any client related error; this could be caused by connection problems.
prasoc
12
Years of Service
User Offline
Joined: 8th Oct 2008
Location:
Posted: 14th Feb 2009 11:30
It might be because the client had a low-spec computer (my game ran at like 30fps when it is supposed to run at 60), but he said he could see me and he killed me, but he disappeared from my screen (im the host) and the server said he disconnected
Alfa x
14
Years of Service
User Offline
Joined: 1st Jul 2006
Location: Colombia
Posted: 17th Feb 2009 18:35
Quote: "Quote: "Really? Outstanding!!

Before using MikeNet, I was getting 300-500 ms ping times in my game. Now I'm getting a consistent 50 ms."
Here is a more detailed explanation:

Currently the data of a packet is copied once with every mnSend command, and is copied once per client sent to with mnSendAll. So, if I send to 5 clients the packet will be copied 5 times.

In the next version, the packet will not be copied at all in blocking sends, thus speeding up the process and lowering processor usage.

Most noticeable improvements will occur when sending to a large number of clients and when sending large packets."


You are making me happier than ever! .

ho yeah!
AlexI
16
Years of Service
User Offline
Joined: 31st Dec 2004
Location: UK
Posted: 22nd Feb 2009 13:01
When are we going to see this release?
Thanks,
Alex

Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 22nd Feb 2009 21:20
I'm aiming to release it within the next 2 weeks.
AlexI
16
Years of Service
User Offline
Joined: 31st Dec 2004
Location: UK
Hayer
15
Years of Service
User Offline
Joined: 4th Nov 2005
Location: Norway
Posted: 1st Mar 2009 11:34
Help im having mega laggs at local network!

Here is my client-code


and here is the server-code


im sending everything through TCP(cause thats more fit able for FPS to dont get any chokey movements.. right? ).

I have tried to turn off my firewall with no difference.

Keep it simple.
Questions? Mail me
KISTech
13
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 1st Mar 2009 17:02 Edited at: 2nd Mar 2009 00:39
Just my guess, you'd be better off using blocking connections.

mnSendTCPAll( 0 , SendPacket , false , true , 0 );

Hayer
15
Years of Service
User Offline
Joined: 4th Nov 2005
Location: Norway
Posted: 1st Mar 2009 17:13 Edited at: 1st Mar 2009 17:26
Server-side or client-side?

Well, I'll do some testing.

Edit:
Well chaning that server-side didnt help much.

true = 1
false = 0

Therefor SendTCPAll( ... block = true aka 1 )

Keep it simple.
Questions? Mail me
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 1st Mar 2009 21:20
Quote: "im sending everything through TCP(cause thats more fit able for FPS to dont get any chokey movements.. right? )."


What is probably happening is that a backlog of packets is building up where packets are being received faster than mnRecvTCP is able to deal with. You can check for this by displaying the return value of mnRecvTCP which indicates the number of packets in waiting; if it is above 5 and rising then lag is likely to occur.

For packets where a large number will be sent per second e.g. player positions/angles, UDP should be used. For an explanation of why have a look at the documentation (MikeNet General Information.doc).

If positions are being sent, only the most up to date positions will be received by mnRecvUDP and old ones will be discarded. For an example have a look at the cube world demos.
KISTech
13
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 2nd Mar 2009 00:41
Mike is right. UDP is best for movement.

Hayer
15
Years of Service
User Offline
Joined: 4th Nov 2005
Location: Norway
Posted: 2nd Mar 2009 23:36 Edited at: 2nd Mar 2009 23:39
This code


server-side, seems to produce a error about that the buffer(SendPacket) is to small or dosn't exist. How is that possible? I create it at the start of the program :s

bug? hope not


Edit:
Got a idea and it fixed the problem.
Placing the

long long int SendPacket before the main function..

But forgot to say that it returns a error about the "mnDeletePacket" at the end, and then points me to some asm, or hex

Keep it simple.
Questions? Mail me
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 2nd Mar 2009 23:53
The error message you describe appears when an unknown error occurs which normally means the packet was not created (but in this case it was).

All of the problems are probably due to the following issue. You are editing memory outside of your Clients array:

In this section of your code:


"ClientData Clients[MaxClients];" should be changed to ClientData "Clients[MaxClients+1];".
Hayer
15
Years of Service
User Offline
Joined: 4th Nov 2005
Location: Norway
Posted: 3rd Mar 2009 00:08 Edited at: 3rd Mar 2009 00:28
Ops, my mistake, didnt think about C++ had zero-based indexes.

Thanks for a quick answer



New question:

For some wierd reason my client gets disconnected from the server when im sending the "walk" command. MikeNet disconnects the client if it is sending dumb-data(for flowing servers etc), but i cant seem to send my data right, cause i get disconnected anyway:s

server


client

please, big guru over all networking, take a look at this code and corret my wrongs.

Keep it simple.
Questions? Mail me
Hayer
15
Years of Service
User Offline
Joined: 4th Nov 2005
Location: Norway
Posted: 3rd Mar 2009 14:38
Porblem soloved.

Have a look in the documentation(which is the greatest doc I've ever seen for a free DLL ) for mnStartServer and read at Operations.


Now I got a new problem.

This is how I write my data


this is how I read it when I recive it at the client-end


I tough MikeNet required the



and read them and moved the cursor by it self

Keep it simple.
Questions? Mail me
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 3rd Mar 2009 16:53
Quote: "please, big guru over all networking, take a look at this code and corret my wrongs."



Have a look at "MikeNet General Information.doc"; in the UDP section UDP modes are explained in detail.

In UDP mode "per client, per operation" MikeNet actually removes the client ID and operation ID from the packet (it doesn't just move the cursor along).

Take a look at the cube world demos, they show how you should implement UDP using "per client, per operation".
Hayer
15
Years of Service
User Offline
Joined: 4th Nov 2005
Location: Norway
Posted: 5th Mar 2009 16:38
Hi Michael.

One more annoying question:
Does mnGetClientID send any packets to the server? Just wondering if I could use mnGetClientID like 50 times inside my mainloop without flooding the server.

Cause, if I add this

int MyPlayerID = mnGetClientID( 0 );

before my mainloop it just gets a wierd value like 65124 or something :s

Keep it simple.
Questions? Mail me
KISTech
13
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 5th Mar 2009 17:42
I actually send the client their ID upon connection.



Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 5th Mar 2009 17:56 Edited at: 5th Mar 2009 18:08
During the connection process (mnConnect) the maximum number of players, number of operations, UDP mode and client ID are received. No data is transferred when using mnGetClientID, it simply returns a stored value.
Hayer
15
Years of Service
User Offline
Joined: 4th Nov 2005
Location: Norway
Posted: 5th Mar 2009 20:18
As I tought, just had to be sure. Thanks for a fast replay

Keep it simple.
Questions? Mail me
Hayer
15
Years of Service
User Offline
Joined: 4th Nov 2005
Location: Norway
Posted: 5th Mar 2009 21:06 Edited at: 5th Mar 2009 21:13
Nevermind my stupidity

Keep it simple.
Questions? Mail me
KISTech
13
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 6th Mar 2009 00:35
There are no stupid questions, only stupid answers. Sort of like the one I gave earlier, which didn't address your qeustion at all.

KISTech
13
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 6th Mar 2009 21:00 Edited at: 6th Mar 2009 22:04
Nevermind, I figured it out.

Hayer
15
Years of Service
User Offline
Joined: 4th Nov 2005
Location: Norway
Posted: 6th Mar 2009 22:43
Eh-h, im having a small problem.

My local ip is 10.0.0.4 and people use my external ip to connect(www.whatismyip.com). But what do I need to do in my router? Read something about NAT, and stuff, but tought I would ask before I messed up my router.

Keep it simple.
Questions? Mail me
KISTech
13
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 7th Mar 2009 00:45
You just have to set up Port Forwarding.

Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 7th Mar 2009 13:34 Edited at: 26th Mar 2009 01:34
Next version's progress
It is pretty much finished, all that is left to do is run some final tests.

Hold your breath: I am planning to turn this project commercial with the help of TGC. If all goes to plan, MikeNet will soon no longer be free. Don't worry though, the price will probably be around $20 (hopefully within your budget); this will give you access to all future updates. The next version will be the first version that is not free and so it may take longer to release whilst agreements are finalised with TGC. The name of the plugin may change but the internals will not (e.g. commands will still have a prefix of mn); the new name is currently planned to be DarkNet.

The following will be in the next version:
-UPnP commands: to set up port forwarding programmatically. The following new commands will be used to accomplish this:


-Faster sending: Currently the data of a packet is copied once with every mnSend command, and is copied once per client sent to with mnSendAll. So, if I send to 5 clients the packet will be copied 5 times. In the next version, the packet will not be copied at all in blocking sends, thus speeding up the process and lowering processor usage. Most noticeable improvements will occur when sending to a large number of clients and when sending large packets.

-MikeNet's code has been split up into multiple files to make management of the project easier. Due to this, error message boxes have changed slightly as they now include the source file as well as the line number at which the error occurred within MikeNet. Similarly there is now an mnGetErrorFile command which returns the source file where the error occurred.

-You can now use mnGetVersion to determine the version of MikeNet currently in use (as a string).

-Some new error messages have been added, some of which can be disabled with a new command "mnDisableDebug" which controls error messages on the server side that could be triggered by a rogue client sending invalid data.

-Demo code has been updated to improve readability.

-The following bugs have been fixed:

1. mnConnect and mnPollConnect now correctly return 0 when the connection times out. In v1.1.1 they returned -1 in this situation.

2. Connection packets from the client can no longer be received in UDP mode catch all. Previously packets with a prefix of 0 (integer) could be received by the server shortly after a client connected in UDP mode catch all.

3. In C++ deallocating a string with delete[] will not cause a crash when the return value of mnGetStringC is an empty string due to an error occurring.

4. Fixed rare occurance of heap corruption during mnFinish due to freeing of resources before closesocket operation completed.

5. Fixed memory leak occurring where mnFinish did not deallocate packet stores (e.g. TCP received packets that had not yet been received via mnRecvTCP).

6. Changed mnGetPhysicalCPU and mnGetLogicalCPU so that if no CPU cores are detected a value of 1 is returned. This fixes a rare case where mnStart creates no threads when number of threads is set to 0.

7. Fixed the return value of several commands that were returning wrong values. This bug was normally only apparent in the event of an error.


Attached is a demo application that shows how UPnP can be used to add, edit and delete port maps. If you get any errors whilst using it then your router may not support UPnP, UPnP may not be enabled on your computer or UPnP may have malfunctioned:


[edit] Updated change list

Attachments

Login to view attachments
Tv Xxx
13
Years of Service
User Offline
Joined: 23rd Sep 2007
Location: Behind You!
Posted: 7th Mar 2009 15:27
Firstly WOO! UPnP

Finally me and Dale2507 have wanted this for ages, and asked for it

Secondly, Good on you on making some money from your work

Thirdly, Grr at making me spend my money, but to be fair, it will be well worth it

gotta love mikeNET, and to me thats what it will always be called

Good luck,

Yours
Tv.


Click my signature for free webhosting!
KISTech
13
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 8th Mar 2009 22:05
I totally agree.

I'll happily purchase this when it's available. Much of what I'm doing now couldn't have been done without it. In fact I'm in the middle of a complete rewrite of my project to incorporate a new server architecture based on the added capabilities that MikeNet gives.

Fantastic that you're going to sell it through TGC. You certainly deserve compensation for your work on this, and your devotion to supporting it.

dale2507
12
Years of Service
User Offline
Joined: 1st Apr 2008
Location: My own little world...
Posted: 11th Mar 2009 01:03
couldn't ave put it better than tv-xxx. although i'd ave probably put finally after secondly and thirdly gotta love a geeks english skills
AlexI
16
Years of Service
User Offline
Joined: 31st Dec 2004
Location: UK
Posted: 13th Mar 2009 01:12 Edited at: 13th Mar 2009 01:13
Yay new version D'Oh no more new versions

Hayer
15
Years of Service
User Offline
Joined: 4th Nov 2005
Location: Norway
Posted: 16th Mar 2009 17:20
Hi again, im having a small problem and im hoping someone here could help me out.

This is the connect-code before the main-loop, it fails at mnConnect(server-side).


Here is the server-side code handling the join-event



And it quits with the error -1 saying that the packet dosnt exist :s

If I set Joined = 0 insted of mnClientJoined(0) I dosnt get the error, but the client just freezes. Help please :/

Keep it simple.
Questions? Mail me
Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 16th Mar 2009 18:08
I can't see anything obviously wrong with your code. It would help if you gave more information about the MikeNet error (e.g. provide a screenshot). If the command that caused the error is mnAddStringC then it is likely that the string you are passing to it is invalid.

As far as the client freezing is concerned, this is probably due to a mistake in your code or a plugin you are using. Note that if you use mnConnect in blocking mode then the client will freeze until it connects or the timeout expires.
KISTech
13
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 16th Mar 2009 18:09
I've been getting that error off and on. The times that I've solved it, it turned out to be the packet I was receiving wasn't the same size or layout as the packet I sent.

Reading a dword, when only a word was sent, etc..

Michael P
14
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 16th Mar 2009 19:51
Quote: "I've been getting that error off and on. The times that I've solved it, it turned out to be the packet I was receiving wasn't the same size or layout as the packet I sent.

Reading a dword, when only a word was sent, etc.."

When getting data from a packet, no error will occur if something goes wrong but the return value can be unusual, especially if you try to e.g. get an integer from part of a packet that contains string data. When not enough space is left in the packet for you to complete a get operation, 0 or a blank string will be returned.

MikeNet errors never occur when getting data from a packet because rogue clients could send invalid data to the server. In the next version there is a new command "mn disable debug" which disables some new MikeNet errors. The new errors aid debugging but can be caused by rogue clients sending bad data.

Login to post a reply

Server time is: 2021-02-27 22:06:06
Your offset time is: 2021-02-27 22:06:06