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
Uncle Sam
18
Years of Service
User Offline
Joined: 23rd Jul 2005
Location: West Coast, USA
Posted: 2nd Sep 2008 07:51
Link
This looks neat. I was just wondering though, how is this any different than Multisync?

Back to top
Profile PM Email
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 2nd Sep 2008 11:15 Edited at: 2nd Sep 2008 13:06
Link
@ sydbod
Thankyou for reporting this issue.

[edit]
Here is exactly how MikeNet's connection process works.

Note: the client connects its TCP and UDP socket to the IP and port specified by the mnConnect parameters ensuring that the address data for both is identical.

Client
1. The client connects its tcp socket to the server
2. The client waits for 16 bytes of data to be received (max clients, max operations, udp mode) via TCP.
3. The client allocates memory based on this received data and connects the udp socket.

Server
1. The server checks to see if any new connection requests exist and decides whether or not to accept the connection if one does exist. We assume that the connection is accepted so that we can continue.
2. The server finds the address of the client during WSAAccept which is used to create a new TCP socket for the client.
3. The server adds this address data to a list that is used to determine the client id that a UDP packet belongs to; all packets from an address that is not in this list are discarded.
4. The server sends the 16 bytes mentioned earlier via TCP.

Therefor, I can be fairly sure that the problem is:
Quote: "The UDP port from the client software will be mapped to a random UDP port on the internet side of the Router."

Quote: "3. The server adds this address data to a list that is used to determine the client id that a UDP packet belongs to; all packets from an address that is not in this list are discarded."


When I have enough time I'll have a go at sorting this out. Its not going to be too easy though . Until then, avoid NAT.

@ Uncle Sam
The ability to use UDP in MikeNet makes it more suitable for fast paced games. That is the main difference between MikeNet and Multisync.
Back to top
Profile PM Email
sydbod
15
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 2nd Sep 2008 13:08 Edited at: 2nd Sep 2008 14:42
Link
@ Michael P,

Thanks for the quick reply.

EDIT: I am glad you will have a look at this.


The problem is that MOST people are now running their machines from behind a ROUTER. (therefor their traffic uses Network Address Translation).
Most people do not know how to disable NAT and run a single machine from the Red interface of the modem.
Likewise those that do manage that will have a significant proportion that will then mess up their firewall settings when on this Red interface.

Potentially 70% of people on the net will be having problems with this particular issue.

The second major issue is that it will not be possible for more than 1 person on one internet connection to use one server.
It will not be possible to have 2 family members playing on one server, let alone on different servers as only 1 machine will have internet access if NAT is disabled.

Should you require any help in this area, I am more than prepared to help you sort this out.
I would very much like to see your library be as good as it possibly can, mainly because I DO want to use it in my project.
You are on a winner with this library .... please consider going the extra few yards with the development.

Just some more information.
I have been running a few more tests between a few friends (friends are all over the world).
The client server code runs fine over straight Non-NAT connections.
So far not a single failure.
We have also been testing through a VPN (Hamachi) and this has proven to be very successful also, with no technical problems.

The only difficulty we were having early on in the tests was with allowing the the server to find its own IP on a machine.
Most of our group have at least 3 network interfaces active at the one time in each of our machines, so we just added some extra front end code to your code to enable us to select Interface IP, Interface Port, Server MaxPlayers.
This way we have full control and let us test with greater certainty of the outcome.

Once again, thanks for a great product, keep up the good work, and please ask if you require any help.
Back to top
Profile PM Email
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 2nd Sep 2008 16:57 Edited at: 21st May 2009 14:38
Link
Me vs NAT - Round 1
You persuaded me to invest some time today fixing this problem . I think I have it more or less sorted. Please could you test this preliminary beta version for me (which is attached) to check that it does in fact work with NAT. You should note that I have not updated the maximum/minimum limits that mnConnect and mnStartServer have and so as a precaution I would set all the sizes to 1024. The new connection system works in pretty much exactly the way you mentioned in your earlier post; fingers crossed it will work .

Let me know how you get on.

DarkNet - multiplayer plugin
Back to top
Profile PM Email
sydbod
15
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 3rd Sep 2008 09:18 Edited at: 3rd Sep 2008 09:22
Link
Quote: "Me vs NAT - Round 1"


It is a success

Clients now no longer have to worry about "Port Forwarding" (only limited testing at this time)

No matter what a person does, a game server will always require its ports forwarded, but there is no practical way around this.

I will test things more thoroughly with a few more associates later tonight when they are online.
Back to top
Profile PM Email
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 3rd Sep 2008 09:22
Link
Brilliant . Some time this week (probably tonight) I'll release a finished v1.03 with a few other minor changes.
Back to top
Profile PM Email
sydbod
15
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 3rd Sep 2008 09:32
Link
Hold off on the v1.03 release until I can get some of my files in order and send you more relevant information.

There looks to be a minor issue with how paramaters are passed into the mnConnect() function.

ConnectIP and LocalIP are the problem entries.

I will get my source together so you can see what I have done and a proper explanation of the nature of the problem.

It may be worthwhile to sort this problem out at the same time.
Back to top
Profile PM Email
sydbod
15
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 3rd Sep 2008 14:47
Link
I have provided the project files for a modified "CLIENT".

I am using
// Set the local IP of the client, if we set this
// to nothing then MikeNet will find our IP for us
//char * LocalIP = "";
char LocalIP[128];

// Set the IP to look for the game server
char ConnectIP[128];

to replace the strings you were using.

The problem is as follows.

Whenever "char * LocalIP" and "char * ConnectIP" is used for passing information into your "mnConnect( )" function , everything is fine.

Whenever "char LocalIP[128]" and "char ConnectIP[128]" is used for passing information into your "mnConnect( )" function , we have problems.

Both ways the code compiles.
Both ways the client program does what the code tells it to do.
Both ways the getting into the game and the running within the game works fine.

The problem way causes a problem when 2 clients have come into a game.
One client can leave normally.
The second client , when he leaves, gets an error message.

I can not understand why, as both of the methods for passing in the data equate to the exact same pointer to the exact same data.

Maybe you can see what is going on. I suspect it is within your "mnConnect( )" function , but it could be that I am missunderstanding some subtle aspect of the C language.

Attachments

Login to view attachments
Back to top
Profile PM Email
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 3rd Sep 2008 16:56 Edited at: 3rd Sep 2008 17:07
Link
This problem doesn't appear to be an issue with MikeNet. What you are experiencing is a buffer overrun and I think that this is being caused by a missing null terminator at the end of the IP addresses being passed to mnConnect. At the end of a c string there must be a null terminator which is used to indicate the end of the string; see this for more information. You should also avoid reusing a buffer without clearing its contents using SecureZeroMemory.

[edit] I'll get back to you on this, going to check a few more things out...
Back to top
Profile PM Email
sydbod
15
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 3rd Sep 2008 18:06
Link
Quote: "What you are experiencing is a buffer overrun and I think that this is being caused by a missing null terminator at the end of the IP addresses being passed to mnConnect."


That was also the first thing I suspected.

You should be able to see this bit of code in the IP Address entry area:
length =strlen(LocalIP);
dbPrint((double)length);

It actually prints out the size of the data in the string up to the first NULL character and displays it on the screen after "LocalIP" has been created and data put into it.

When you run the program it confirms that the data is of correct length and is terminated with a NULL character as it should be.

This problem has been running me ragged for the last few hours.
Back to top
Profile PM Email
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 3rd Sep 2008 18:24
Link
It could be something to do with converting from char[] to char* so you could try doing it manually, perhaps using strdup but I'm definately no expert on c strings. If that doesn't work you should ask on the DGDK forums and see if you are doing anything wrong.
Back to top
Profile PM Email
sydbod
15
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 3rd Sep 2008 19:11
Link
OK Thanks.

I will modify the code and read out the contents of every element is the char array after it gets created.
I will do the same for a string as you have coded it, and compare the difference.

And if I still cant sort it out, I have a friend who is a professional C programmer, and put it into his capable hands.
Back to top
Profile PM Email
sydbod
15
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 3rd Sep 2008 20:09
Link
Here is a code fragment inserted in the code

See the code starting from "//DO A STRING TEST"



Two strings are made in the 2 different ways.
When identical entries are inserted both ways,the "strcmp()" function confirms that the data is identical in both strings and of the same length up to the first NULL character, and it displays "Strings are IDENTICAL".

If different data is deliberately entered between the 2 strings, then the "strcmp()" function does detect it and displays "Strings are DIFFERENT".

The problem has to be in the way the "mnConnect( )" function is handling the string pointers or the data from the string pointers.

I can see no other explanation.
Back to top
Profile PM Email
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 4th Sep 2008 01:21
Link
I will look into this in great detail and find out what exactly is causing the problem
Back to top
Profile PM Email
sydbod
15
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 4th Sep 2008 04:47
Link
Now that I have had a sleep and had another think about it, we may have to do a bit of clean up work on the code as a first step.

To exit the game , we are pressing the "Esc" key or we are clicking on the "Close" button on the window.

Both of these will terminate the program WITHOUT running the "mnFinish()" function.
In other works there is no clean up being done to undo what "mnConnect()" has done.

The problem I am talking about is happening on exit, and not during initialisation or running the game.

It can very easily be that the nature of the data being fed into the "mnConnect()" function can have different outcomes when one terminates the program in this improper way that it is being done at the moment.

I will also look further into this when I get back home later today.
Back to top
Profile PM Email
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 4th Sep 2008 09:40 Edited at: 4th Sep 2008 09:55
Link
In DGDK if you click on the close button, or press the escape key it will run through all of your code until the last line where it will exit. This means that mnFinish is being executed, this is not the problem however since I tried without mnFinish.

Also, there is no reason why not cleaning up with mnFinish would cause any kind of error. Most of what mnFinish cleans is undone automatically upon closing and although bad practice, leaving ports unclosed should not cause errors.

Its a mistake somewhere on my part, I'll be looking into it on Friday.
Back to top
Profile PM Email
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 5th Sep 2008 15:45 Edited at: 5th Sep 2008 15:57
Link
I believe I have found out what the problem was with regards to sydbod's crashing on exit problem. I've run some tests and come to a conclusion; however, if you think this is wrong please let me know.

I am pleased to say that it is not a problem with MikeNet, it is a case of miss using DarkGDK. Apparently, when you perform an operation on an object that does not exist, a buffer overrun can occur. This explains why the problem does not occur when the first client leaves.

I simply changed the client's positioning code to:


The only remaining question is why the crash only occurs when passing a string in a different way to mnConnect. I'm guessing that this uses memory in the area that DGDK was running into.


The next version will be released soon enough (assuming no more nasty problems). I am just adding the finishing touches and then converting it to DBP. You should be aware though that I have far less time now that my holiday has ended
Back to top
Profile PM Email
Oneka
19
Years of Service
User Offline
Joined: 24th Apr 2004
Location: Hampton,VA
Posted: 6th Sep 2008 06:25
Link
Hey I like this little plugin from my day of playing with it

Thanks for it (C++ ver)

Quick question though Ive done a few wierd tests i made up
such as


When this is ran I can see in the command prompt that every so after it takes 15ms to complete the operation above while the majority of the other are 0ms, just wondering why this may be and I know it could be a host of factors but wondering if something within Mikenet may cause it, its not really a bug but just something I noticed... it happens maybe in 100 of those checks


Making dreams possible, one line at a time...
Back to top
Profile PM Email Website
sydbod
15
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 6th Sep 2008 08:08 Edited at: 6th Sep 2008 08:12
Link
@ Oneka,

I have not tried it yet, but it is always best to remove all other possibilities before suspecting anything.

EG:
1)have you confirmed by testing that the clock is actually incrementing in 1mS steps.
2) have you confirmed that the screen refresh is not messing with the time measurement.

It may be interesting to replace "mnAddByte(127);" with maybe a dozen lines of trivial code that does basically nothing but waste a bit of time and only build and extend an array to a size of 1024*5 in elements (do not predefine it to 1024*5 in size, extend it as you build). Then see what the outcome is?



@ Michael P,
Quote: "when you perform an operation on an object that does not exist, a buffer overrun can occur."

I get the same sort of feeling that that is probably the correct reason.
When your updated library is released and people will have had a few weeks to play with it some more, then we should know.
Again, thanks for your time and effort.

If you get the time in your next holidays, maybe you could look towards adding the capability of passing a pointer and data structure size as another variable type to the library when building the UDP data packet. It would make it easier to code for a game developer.
Back to top
Profile PM Email
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 6th Sep 2008 12:51 Edited at: 6th Sep 2008 12:51
Link
@ Oneka
The mnAdd commands are quite slow because memory is reallocated with every add command; this is something I will definitely improve upon in future versions. Note that the get commands are much faster and better implemented.

@ sydbod
In my next holiday I'll implement a lot of improvements to MikeNet
Back to top
Profile PM Email
Oneka
19
Years of Service
User Offline
Joined: 24th Apr 2004
Location: Hampton,VA
Posted: 6th Sep 2008 20:42
Link
Ok, just curious when do you think that an improved version will be made?


Making dreams possible, one line at a time...
Back to top
Profile PM Email Website
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 6th Sep 2008 20:52
Link
Should be within the next couple of weeks. I'll do some performance improvements (including the mnAdd improvements) as well as NAT compatibility for the next version.
Back to top
Profile PM Email
Oneka
19
Years of Service
User Offline
Joined: 24th Apr 2004
Location: Hampton,VA
Posted: 7th Sep 2008 05:14 Edited at: 7th Sep 2008 06:51
Link
Ok that sounds good and thanks

One more question I need to ask of you is what exactly are the difference between UDPMODE_PER_CLIENT_PER_OPERATION & UDPMODE_PER_CLIENT I read the help document but it did not completely answer the question for me, I dont really understand the purpose of whole operation thing and why it would be useful.. So if your not too busy can you just give a quick explanation of the usage and what it would be most effective for? Thanks

EDIT:
I am having problems with using UDP
I have used the TCP packet system just fine and everything worked but when I tried to do the same with UDP ive gotten multiple problems..

USING: UDPMODE_PER_CLIENT

Problem 1
If I do not put mnAddInt() at the start of a packet when sending UDP i get this error "An error occurred whilst dealing with new udp packet. Client Number must be less than or equal to maximum number of clients at line 1238. Error code: '997', Version: 'Release v 1.0.2 CPP (28/8/08)'. Would you like to exit?"

It appears that in that problem I have to first put the interger value of a client that iam sending to even though iam using mnSendUDP(client,false,false) which that does not make sense

Problem 2

EDIT 2:

When I receive the UDP message it appears to be empty and not clearing cache, I have found it is not any other code as this project is very small and the TCP worked out just fine

Due to this problems I cannot properly send UDP packets
If the problem is due to using UDPMODE_PER_CLIENT please show me how to properly use them, becuase using the other method i do not understand the whole "operation client setup" and I do not want to send unneccessary UDP packets to every client on the server just the one that it needs to go to hence why I used mnSendUDP, sorry for the inconvience and here is the code I am using below to send and receive TCP / UDP packets


SENDING (SERVER)


RECIEVING (CLIENT)


Thank you for your time and your plugin, if this is an error on the plugin iam happy to find it if not its my fault lol


Making dreams possible, one line at a time...
Back to top
Profile PM Email Website
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 7th Sep 2008 23:02 Edited at: 7th Sep 2008 23:06
Link
Quote: "One more question I need to ask of you is what exactly are the difference between UDPMODE_PER_CLIENT_PER_OPERATION & UDPMODE_PER_CLIENT"


If each client is only sending one type of packet e.g. a packet containing some floats indicating its position then you should use UDPMODE_PER_CLIENT. If each client is sending more than one type of packet e.g. type 1: some floats indicating its position, type 2: sound in byte form from the client's microphone then you should use UDPMODE_PER_CLIENT_PER_OPERATION.

Quote: "If I do not put mnAddInt() at the start of a packet when sending UDP i get this error "An error occurred whilst dealing with new udp packet. Client Number must be less than or equal to maximum number of clients at line 1238. Error code: '997', Version: 'Release v 1.0.2 CPP (28/8/08)'. Would you like to exit?"

It appears that in that problem I have to first put the interger value of a client that iam sending to even though iam using mnSendUDP(client,false,false) which that does not make sense"


When sending to a client, you must formulate your packet in the following way:

1: Integer - Client id of the client that the packet applies to
2: Integer - Operation id of the operation that the packet applies to (if in UDPMODE_PER_CLIENT_PER_OPERATION)
3: Any further data

The client must then loop checking for new data applying to each client and each operation id. The mnRecvUDP documentation is actually wrong, you cannot ignore the client id parameter in client state when dealing with UDP packets.

Lets say that the server wants to tell all of the currently connected clients the position of client number 5. We would formulate the packet in this order:
1: Integer - Client ID number 5
2: If we were in UDP_MODE_PER_CLIENT_PER_OPERATION we would then put the reposition client operation id here. If not, then we ignore this step.
3: Float - Client 5 position X
4: Float - Client 5 position Y
5: Float - Client 5 position Z

Then we would send this to all of the clients except number 5 (since we assume it does not need to know its own position) using mnSendUDPAll.

I hope this helps you understand how to use UDP in MikeNet. The documentation will be corrected in the next version which is to be released soon enough. Have a look at the code for the cube world demo included in the zip, it demonstrates quite nicely how to use the MikeNet UDP system.
Back to top
Profile PM Email
Oneka
19
Years of Service
User Offline
Joined: 24th Apr 2004
Location: Hampton,VA
Posted: 8th Sep 2008 03:30
Link
Ok thanks for showing me that, and i know iam full of questions but ontop of all the headers what would be the final size of a TCP packet and UDP?

Winsock headers + MikeNet headers? so I can make a rough calculation of the size of packets so if I only add 8bytes of data ill know the other size so I can properly assess bandwidth


Making dreams possible, one line at a time...
Back to top
Profile PM Email Website
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 8th Sep 2008 09:46
Link
The documentation's packet formulation/deformulation section lists the size increment of each mnAdd command. Each packet has a 4 byte prefix (both TCP and UDP). Outside of winsock, I don't know what the real packet size will be, although UDP should be smaller than TCP. Note that during transmission large TCP packets are automatically split down into smaller packets and then recomposed into a single packet at the other end.
Back to top
Profile PM Email
bergice
16
Years of Service
User Offline
Joined: 5th Jun 2007
Location: Oslo,Norway
Posted: 10th Sep 2008 19:49
Link
Can somebody make a dba version of the cube demo?


http://bergice.blogspot.com/ << Please enter my blog and click ads
Demos,Examples,Tutorials,Portfolio
Back to top
Profile PM Email
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 10th Sep 2008 20:22
Link
What is dba? If you are referring to the file extension of dark basic professional source code files (.dba) then there is already a converted example in the download zip.

While I'm posting, I may as well update MikeNet user's on the progress of the next version.

I've finished and tested:
-The new NAT compatible connection system
-Performance improvements to the mnAdd commands
-Performance improvements to the mnSend commands

I also want to do the following for the next release:
-Performance improvements when receiving new TCP packets
-Make possible multiple connections/server hosting in one application

I am on track for release by the end of Friday the 19th. However, if I encounter major problems the release may be delayed until some time during the week after (between the 21st and 26th).
Back to top
Profile PM Email
bergice
16
Years of Service
User Offline
Joined: 5th Jun 2007
Location: Oslo,Norway
Posted: 10th Sep 2008 20:49
Link
Thanks, it wasnt there when i looked tough, weird


http://bergice.blogspot.com/ << Please enter my blog and click ads
Demos,Examples,Tutorials,Portfolio
Back to top
Profile PM Email
sydbod
15
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 10th Sep 2008 21:02
Link
@ Michael P,

I have hit a snag.

Each player machine has to be able to find out what "iPlayer" itself actually is.

I have a line of 32 aircraft sitting on the runway.

As a player joins the game he has to find out what his "iPlayer" ID number happens to be so that he can get into the correct aircraft.
iPlayer = 1 gets first aircraft
iPlayer = 2 gets second aircraft
etc....

I have looked through the documentation but I can not find how the above is meant to be accomplished.

Any suggestions would be greatly appreciated
Back to top
Profile PM Email
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 10th Sep 2008 21:12 Edited at: 10th Sep 2008 21:15
Link
From your last post I believe you want to know how to tell a client what its client id is?

In the new version (soon to be released) I have implemented a command called mnGetClientId that does this for you. Until this is released the server should send a TCP packet to a new client containing its id as it joins.

Using the system of codes that allows your application to act differently depending on what the packet is intended for, you can add a separate code indicating that the rest of the packet contains the player's client id.

Back to top
Profile PM Email
sydbod
15
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 11th Sep 2008 05:23
Link
Thanks for that information.

I was a little slow .... it took me a bit of time to realise what you were actually saying.

I finally modified the server code to send a joining client its ID number as it joins, and Added the lookup for that code and ID within the received TCP packets for the client.

All is running fine now.

Time for some serious testing when I get back later tonight.

Thanks for that
Back to top
Profile PM Email
Oneka
19
Years of Service
User Offline
Joined: 24th Apr 2004
Location: Hampton,VA
Posted: 11th Sep 2008 15:37 Edited at: 11th Sep 2008 15:38
Link
Hey Michael P

I was wondering if it was possible with the UDP commands just to be able to send data without having to worry about the first 2 prefixes (Client and operation) because in some cases I would not need the Client at the begining of the code as it would be a waste of 4 bytes, and also I didnt understand why I needed the client number ontop of alreadying listening the target with mnSendUDP

For example instead of doing this

mnAddInt(Client)
mnAddInt(Operation)
mnAdd(Rest of Data)
mnSendUDP(Target,false,false)

I want to just do this
mnAddInt(Operation)
mnAdd(Rest of Data)
mnSendUDP(Target,false,false_

If you can add this ability to MikeNet I think it would be great because I can use less bandwidth by not having to send uneccessary data such as client numbers that I dont use, unless that is setup so that it is sent to the right client but in that case I wouldnt understand the purpose of having that ontop of having a client_id for mnSendUDP in place already...




Making dreams possible, one line at a time...
Back to top
Profile PM Email Website
sydbod
15
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 11th Sep 2008 16:40
Link
Interesting idea.

Just wondering about the following possibility.

If you have mixed packet types where some of the UDP data that you send does use the Client and Operation fields, there would be a very high possibility that when you send a packet that is missing these entries, then at times some of these would have data at the front of the packed that would match data wise with an entry that is a valid Client and Operation entry.

You would have to have some very fancy code to catch such an event.
Back to top
Profile PM Email
Oneka
19
Years of Service
User Offline
Joined: 24th Apr 2004
Location: Hampton,VA
Posted: 11th Sep 2008 18:03 Edited at: 11th Sep 2008 18:09
Link
Well that also bring up the point of having users making faulty packets, this could also mess with the flow of the program.

Now I remember another important question I needed to ask, which is the ability to check to see if there is anymore data left in the packet to be read for events like that so I can make my own error handling of packets.

maybe a command like
mnDataAvailable or something that can return the number of bytes left within a message to be read

because my current understand this would affect the current setup and the other if this is not implemented because we are going on the basis that the client program or server program is sending 100% perfect data back inforth

so in events like



So in that case it would try to read data that is not available so I suggest maybe something like this you can do



If these 2 commands are added it would improve upon the stabillity when it comes to packets like you mentioned above


Commands suggested:
mnDataAvl() - will tell you how big a packet is in bytes or how much data is left, either one would be good (probably the first 1 would be best) (used after mnRecvTCP or mnRecvUDP)

mnSendUDP(client_id,raw mode (boolean),keep packet,block till sent) - with a mode to just send raw data to a client (just like TCP)


Making dreams possible, one line at a time...
Back to top
Profile PM Email Website
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 11th Sep 2008 19:23 Edited at: 11th Sep 2008 19:23
Link
@ Oneka
The purpose of the client id and operation id is to enable MikeNet to decide what to do with UDP packets as they come in.

It is possible for me to implement another UDP mode which lets you receive packets purely on the basis of operation id, ignoring client id. I will look into doing this at some point in the future.

I also intend to implement a system that you can use instead of the mnRecv commands whereby you pass a pointer to a function to MikeNet and every time a packet is received this function is executed. This will be of higher performance than the mnRecv commands and will also allow for greater UDP functionality since you control what to do with each packet rather than relying on the UDP mode system that we have at the moment.

There is already a command that returns the number of unread bytes that are left in the currently received packet which I missed from the documentation: int mnGetPacketRemainder().

The mnGet commands return 0 or an empty string when there is nothing left in the packet to return. When MikeNet encounters anything wrong (e.g. an operation id that is too high) that relates to an individual client, the client is automatically kicked.

@ sydbod
Yes, you would see strange results because MikeNet uses the client id and operation id value to determine what to do with incoming UDP packets.
Back to top
Profile PM Email
sydbod
15
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 13th Sep 2008 17:40 Edited at: 14th Sep 2008 09:58
Link
@ Michael P,

Just a bit of an update about what we are doing with your library, and how it is performing.

We have it integrated into a 32 player crude combat flight sim.

So far we have had up to 6 clients connected at the one time.

We have run tests over some very lousy internet connections, and are finding that for us, our data packets will have to include time stamp entries so that we can drop late arriving packets (out of order packets) ..... we can do this in our data structures.

The only real problem we have come across is that the library is not happy playing with some other applications. I have not pinpointed what the actual trigger is, but it can lead to the server locking up and at the same time locking up other applications. (will look into this a bit later)

The current major problem is that if a client happens to drop from the server due to the client machine locking up, the server does not look to be cleaning up its internals that were set for that client.

Sometimes, depending upon what is actually happening, the server can lock up and drop every other client during one of these client drop outs, and the server will then no longer be accessible from any client, without the server being reset.

Now the very good news.

We have no problems connecting clients from behind routers or from direct modems.

We have also had the server behind a router (NAT) with port forwarding enabled in the router, and clients have had no problems to connect to the server.

So far things are looking very sweet.

Am looking forward to your next update whenever you are ready to release it.
Back to top
Profile PM Email
Oneka
19
Years of Service
User Offline
Joined: 24th Apr 2004
Location: Hampton,VA
Posted: 14th Sep 2008 22:18
Link
@Michael P,

I dont know if this is an bug or not but I noticed when recieving UDP messages, it does not clear the buffer of the packet after reading the data



So in some cases I get the same packet over and over again and while this is not really a problem I guess it would be good for postion data etc testing just the functionality of UDP makes it act funny as I would expect it to work like TCP commands onced recieve and read it is gone..


Making dreams possible, one line at a time...
Back to top
Profile PM Email Website
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 14th Sep 2008 22:46 Edited at: 14th Sep 2008 22:47
Link
@ sydbod
Quote: "are finding that for us, our data packets will have to include time stamp entries so that we can drop late arriving packets (out of order packets) ..... we can do this in our data structures."

MikeNet should automatically discard packets that are older than the last received packet but I will run some tests before the next version.

Quote: "The only real problem we have come across is that the library is not happy playing with some other applications. I have not pinpointed what the actual trigger is, but it can lead to the server locking up and at the same time locking up other applications. (will look into this a bit later)"

This is strange, what applications cause this to happen?

Quote: "The current major problem is that if a client happens to drop from the server due to the client machine locking up, the server does not look to be cleaning up its internals that were set for that client.

Sometimes, depending upon what is actually happening, the server can lock up and drop every other client during one of these client drop outs, and the server will then no longer be accessible from any client, without the server being reset."

I believe this problem is not present in v1.02 but is new to the beta v1.03 that I posted earlier. I think I fixed this while testing the connection system.

@ Oneka
I will fix this for the next version.
Back to top
Profile PM Email
sydbod
15
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 15th Sep 2008 02:13
Link
@ Michael P,
Quote: "MikeNet should automatically discard packets that are older than the last received packet but I will run some tests before the next version."

I based that on the appearance of what happens to aircraft in a laggy connection. It was looking like we were getting the occasional backwards motions under certain adverse internet conditions. at the moment it could only be explained by late arriving packets. Don't spend too much time on this particular problem, as what I suspected may even be incorrect until I have more time to do some thorough readings, and the other problems are much more important.

Quote: "This is strange, what applications cause this to happen?"

If we run one instance of the server on a single machine, and then run one instance of the client on the same machine.(They are set to use the same interface IP number, but use different port numbers. Usually on the second time the client connects to the server, the crash happens ... although sometimes on the first connection, the crash will happen.
After this type of crash, the server usually has to be restarted, for it to function again.
We have also had crashes when Acrobat reader was started, while TeamSpeak2 client was running and then a game client was started. (this particular type of crash would take down the machines whole Network system, and required us to restart the machine.
We have had crashes that took out the machines network when TeamSpeak2 voice client was running, a Server instance was running, and then another game (European Air War) was started.

Quote: "I believe this problem is not present in v1.02 but is new to the beta v1.03 that I posted earlier. I think I fixed this while testing the connection system."

This is currently the major problem that we can not work around.
If it is fixed, then that is great.
We may be able to get a major ISP in Germany to host a free server instance for our testing purposes in 2 weeks time (we are waiting for some one to come back from holidays), so this problem is the most important for us.

Now on to other ideas:
In a previous post I mentioned that it may be nice to have a data type that is a pointer to a structure with a size of a structure entry.
If this sort of data type is possible, then it would enable us to create a generic server, where we could send any sized data packet, and the server would be able to retransmit it, no matter what size.
This would be great for development, because one would not have to create a new server with new data formats, every time the format of the data is changed within the client (during development).
This would save a lot of mucking around getting the person/company to reload and restart a different server. (just an idea)
Back to top
Profile PM Email
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 15th Sep 2008 19:09
Link
Quote: "If we run one instance of the server on a single machine, and then run one instance of the client on the same machine.(They are set to use the same interface IP number, but use different port numbers. Usually on the second time the client connects to the server, the crash happens ... although sometimes on the first connection, the crash will happen.
After this type of crash, the server usually has to be restarted, for it to function again.
We have also had crashes when Acrobat reader was started, while TeamSpeak2 client was running and then a game client was started. (this particular type of crash would take down the machines whole Network system, and required us to restart the machine.
We have had crashes that took out the machines network when TeamSpeak2 voice client was running, a Server instance was running, and then another game (European Air War) was started."

A lot of MikeNet has changed since the early v1.0.3 beta and so it is likely that I have fixed these issues. Hopefully in the next version you shouldn't have any problems.

Quote: "Now on to other ideas:
In a previous post I mentioned that it may be nice to have a data type that is a pointer to a structure with a size of a structure entry.
If this sort of data type is possible, then it would enable us to create a generic server, where we could send any sized data packet, and the server would be able to retransmit it, no matter what size.
This would be great for development, because one would not have to create a new server with new data formats, every time the format of the data is changed within the client (during development).
This would save a lot of mucking around getting the person/company to reload and restart a different server. (just an idea) "

I may look into implementing something like this in the future. Not for the next version though, my to do list is already quite long.

Progress Report
I've just finished some major changes to the TCP receiving system which should dramatically increase performance, especially when dealing with a large backlog of packets. I plan to make a few changes to UDP that should boost performance when multiple threads are involved and then after testing that I will move onto making multiple connections/server hostings possible within the same application.
Back to top
Profile PM Email
Oneka
19
Years of Service
User Offline
Joined: 24th Apr 2004
Location: Hampton,VA
Posted: 15th Sep 2008 21:12
Link
Cool so have you added any support for sending raw UDP messages like you can with TCP? (Meaning not requiring a client ID or operation ID so that the coder can have as much freedom as they need, just cuz lol) and also fixing the cache not clearing


Making dreams possible, one line at a time...
Back to top
Profile PM Email Website
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 15th Sep 2008 21:20
Link
I can't make UDP operate in the same way that TCP does because the amount of traffic would cause it to clog up. However, I intend to implement a way of passing a function pointer to MikeNet. This function will then be executed every time a new message is received giving you complete control over your UDP packets; using this function system, the UDP mode system is ignored.

This will take me a while to implement and so I won't be able to do it for the next version. I will be working on it for following versions so you should see this implemented in a few weeks time.

I have not forgotten the UDP cache not clearing, I'll be fixing that tomorrow
Back to top
Profile PM Email
RedFlames
16
Years of Service
User Offline
Joined: 25th Aug 2007
Location: Germania
Posted: 15th Sep 2008 21:49
Link
hey i hadn't used this for some time and i think you told me that the bug with sending a String together with other data via TCP is fixed... but i definitly installed the new version and even put it next to the Exe, and i still cant send those strings together with other data. (only tested localhost for now though)
I hope you can help me clearing this up/fixing it

Back to top
Profile PM Email Website
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 16th Sep 2008 00:44
Link
If you look back at earlier posts you can see that when I ran your test code I had no problems. Here are a few suggestions that may help you solve the issue:
-Search your computer for MikeNet.dll and delete all occurrences
-Install MikeNet from here
-Ensure that the TCP receive buffer sizes are large enough

If that doesn't help then attach the projects that you are working with and I will see if I can find out what is wrong.
Back to top
Profile PM Email
Emphasoft
16
Years of Service
User Offline
Joined: 2nd Jun 2007
Location: Deep Underneath the Center of the Earth
Posted: 17th Sep 2008 15:00
Link
could you upload the plugin to the forums? my internet blocks "uncategorized" web pages

I admire its purity, a lone survivor, unclouded by delusions of morality or conscience. -Parker, from ALIEN.
Back to top
Profile PM
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 17th Sep 2008 16:16 Edited at: 21st May 2009 14:39
Link
v1.0.2 is attached to this post

DarkNet - multiplayer plugin
Back to top
Profile PM Email
KISTech
16
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 18th Sep 2008 18:14
Link
I was hoping something would come out that was a middle ground between MultiSync and RakNet. I look forward to trying this out on the next major update to my project.

Nicely done from what I've seen so far..

Back to top
Profile PM Email Website
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 19th Sep 2008 21:23 Edited at: 20th Sep 2008 10:33
Link
While testing the new version I found a nasty bug that I need to fix before the next release. This bug is an access violation that can occur when a client disconnects causing the server to crash. I believe this is caused by the server deleting the client's information whilst a thread is reading it.

Give me a few weeks tops to fix this and check through MikeNet for any other bugs. Sorry that I didn't manage to get everything sorted for today, I did try .

The next release will include:
-Performance increase for receiving via TCP and UDP
-Performance increase for formulating packets
-NAT compatibility for clients
-Bug fix: mnRecvUDP should clear the old packet but currently does not
-Possibly some other bug fixes

I didn't get round to making possible multiple server hostings/connections but I did restructure parts of MikeNet which should make it easier to implement once I get round to it. I intend to release the next version with the changes mentioned earlier, and then after that begin work on multiple server hostings/connections for future versions.
Back to top
Profile PM Email
sydbod
15
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 20th Sep 2008 13:10 Edited at: 20th Sep 2008 13:12
Link
@ Michael P,

I am thinking of also implementing a Host/Clint mode with your library.

Basically, a player may also act as a server while the other players act as clients.

As your functions allocate "ID 1" upwards for the players, it has left player "ID 0" not used.

If a player is acting as a Host, then I would like to manually allocate (by default with no action being required by the network library) "ID 0" to this Host.

This Host has full access to all the data packets that the server is serving as the Host is running the server code.

Can you tell me the following.
client code :

mnRecvUDP(iPlayer,iCode)

Will this function work properly if iPlayer has a value of "0" and the server is made to send a UDP packet of:

// Relay data to clients
// Formulate packet
mnAddInt(Client);
mnAddInt(CODE_POSITIONPLAYER);

Where "Client" = 0


and
server code:

mnSendUDPAll(false,false,Client);

Will this function also work properly with a value of "Client" = 0 .
Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2024-04-18 21:03:30
Your offset time is: 2024-04-18 21:03:30