Sorry your browser is not supported!

As attached, the network package size is over 1400?
Is this in, bits? byte? char?



The string should not be longer than a standard book paragraph?

Any help appreciated!

It's in astronomical units. Your packet cannot be longer than 1400 times the distance from the Earth to the Sun. It's basic biology dude.

(it's in bytes....)

right...

the string return is basic english ascii, a-Z and 0-9...
It should not be longer than 512 byte...

I wonder if there is a way to increase the string length?

How do one send a 'Package' with sprite and such on an mmo game if we can't send a big package?

Something like runescape where it download it's content?

You can't really increase the MTU for everyone running your game. Your total packet size if using only a string will be 8 X the number of characters plus header data and terminator. So your string is likely over about 170 characters.

If you need to send something larger, you'll need to break it up into pieces and send the individual sections of data. Sequence your packets numerically so you can keep track of where the data needs to go when you reassemble it on the receiving end. Also, consider using floats/integers if you're just sending numerical data (like color data for a sprite/image) as that will help reduce each overall packet's size.

The Maximum Transmission Unit (MTU) is going to typically be 1500 Bytes., AppGameKit is likely limiting this to 1400 Bytes because there are some exceptions depending on the Connectivity as well as the Overhead that AppGameKit adds.

Now specifically this will directly relate to Connection Latency...
For example MTU 1500 on a 14.4K IPX would result in a 1000ms Latency., this as a note is why typically IPv4 actually uses 68 to 64000., in general the MTU would be Automatically adjusted to maintain a 1:4 Ratio. (i.e. 375 @ 14.4K, 750 @ 28.8K, 950 @ 36.6K and 1455 @ 56K)

On Connections above this., we then begin to see a reduction from 250ms Latency for Real-Time Packets.
So for example a 2Mb Connection with MTU 1455 would result in a Peak 56ms Latency., where-as MTU 1500 would Peak 60ms.
10Mb would drop this further to 12ms., etc. etc.

Now the way most High-Speed Broadband handle things is perhaps more notable; as essentially they will still Peak at 8 - 12ms but instead have additional Lanes for every 10Mb
So for example my 360Mb connection has 32 Lanes., 11.25Mb / Lane and a Peak Latency of 8ms.
If AppGameKit Support this though is well unlikely., it's more likely to simply use a Single Dedicated Network Layer / Lane.

The point I'm making is regardless., the MTU remains fairly static.
As such the 1400 - 1500 Bytes is always going to be a limitation for Packet Sizes you'll have to work within.

I end up using a different crypto...
this no longer hash it...

I am just getting around to playing with the packets.

In the past though when sending nonsensitive game data through the browser using GET, I only hashed a checksum that used a private key in addition to the data.

That way, if anyone tried to manually change the data in the path, the hash didn't match and my script on the server would reject it.

The private key prevented them from changing the data and then hashing it to change the hash as well, so it worked great for my needs.

So, the only thing hashed was the checksum.

I haven't gotten around to it yet, but my packets will be about 157 characters of payload so far, so I guess I am going to have the same type of error trying to send them.

Wasn't really trying to break them up in sections, but...

Thanks guys for sharing your expertise. (hopefully I can avoid it now before it happens)

the hash seem to increase it as much as 20x the string size...
Kinda wish AppGameKit network multiplayer has it's own build in SSL protocol for this...
A new SSL cert every 5 minutes type of security?

This could prevent network snooping to change a 'int' to the server...

Not sure which way you are hashing it, but that doesn't sound right.

Unless of course your string was only 3 characters long.

Sha256 would make it 32 characters long (256 bytes), and the sha512 would be 64 characters long (512 bytes), right?

I have two sha256() hashes I need to use, which eats up a lot, so I can't use the 512.

I guess my use of the word 'salt' is different than others, because I thought the salt could be extracted from the hash appendage rather than being secret, which I call the private key.

I've always had difficulty wrapping my head around other people's work though, and the cryptography is no exception, so I usually develop my own proprietary methods when really concerned.

The sha256 has worked great for gaming stuff, and even cryptocurrencies usually just double it sha256(sha256(string$)) for an added layer.

I didn't know about the base58check encoding when I was working on my steganography, but I had developed a similar method through original thought accidentally.

I have no clue in what string values you are passing, but if they are fixed/static and not dynamic, then you could always have numeric abbreviations for them, kind of like the way Bitcoin uses the recover method for private keys.

You choose 12 to 24 words from a fixed string selection of 2048 words to generate the 256 digit binary string that represents the private key.

Not saying to do it that way, but if the long strings you are passing are paragraphs of a book, then the data is not being changed, so the transfer could be reduced to the number of paragraphs for instance, then the client could turn that number back in to a string.

For non-dynamic there is no need to transfer the entire string, just an abbreviation that represents it, like a bar code.

Even a fixed number of words could be used dynamically if the number representing each word is less bytes than the words as strings. (like the Bitcoin private key recovery)

I would try that for my work around, but I am dealing mostly with hashes not words, and numeric values and timestamps, so I need to figure something else out.

For now, breaking them up seems the best route, but increases the chance of stuff being lost since two packets need to get there instead one one.

Pretty sure I will need to do transfers of small files anyway though, so I may use this UDP stuff just to trigger the other stuff to happen. ( as I said, I'm a network-noob )

I am not sure?
It uses this library: using System.Security.Cryptography;

This allow it to be decrypted on the other end using a universal salt as well as a dynamic salt...
Not sure why a 103 byte length string could be over 1100 byte when encrypted...

The end result decrypted fine, so the data is not corrupted...

I do not think anyone is truly making simple games like those 'demo' AppGameKit has to... 'teach'?
Those snake and such games?
Actual game maker need a engine that has stuff like network security...
Perhaps some way to put in DRM and ANTI-Cheating such as 'cheatengine' manipulation...
Many other things agk lack that other engine like unity would be easier to add in if it does not exists...

WOW

That isn't 20x, but having it make it 10x longer is terrible.

The salts sound as if it is creating those embedded in the string as well as some junk stuff too just to throw people off. (extra junk is okay for security but not desired for transfer size)

Since it is not a one way hash, then you would probably be better off creating your own method of encryption. (or finding a better one than that)

That way, you could compress it a bit instead of making it longer.

Some string was 50 in len yet it is too long...
Also, it is not a one way hash, it can be decrypted...

I end up creating another encryptor instead...
This one is 1 to 1, and the byte has been shifted to a random 0-255 each...
Each byte is now encrypted...
Yet can be decrypted on the other hand!

I wonder if we could use multiple sendnetworkmessagestring() of 1kb each?
or the full messages total could only be 1400 bytes in length...?

When it comes to Network (Package) Security., there is no Right / Wrong way to go about it... as well there is no method that truly works.
In blunt terms, if there is a way to Decrypt the Data... there is a way to break the Encryption and figure out how to change said data.

Security though is a simplistic concept of simply making the process of Packet Snooping and Exchange more effort than it's worth expending.

With this said., Hash Keys are the WORST method of Security for Real-Time Applications.
The reason being that you cannot "De-Hash" the Information... instead what you're doing is using it as a Obfuscated Compariison.
I mean you strictly speaking could; but due to data collisions; you're not necessarily going to get out what was actually put in., and due to how Hashing works, Re-Hashing what you got out isn't going to produce the same Hash Key.

It's a little involved to delve into., but basically Hash Keys are a great way of just checking that both System A and System B are using the same data without every actually physically sharing said Data.
This is great for Static things that you never actually want to Share outside of an initial Setup... such-as Passwords or other Sensitive Data.
It isn't useful as an Encryption Method for ACTUAL Data you want to be sharing., say like Real-Time Chat, Player Positions, etc.

In-fact it's disgusting easy to keep THAT data safe... remember you want a Real-Time Latency (say 8ms to 250ms) for "Playable" results; so all you need is something that can't be Broken / Injected within said Time-Frame.
Essentially it has to be lightweight., and this is easy enough.

There are two key things to establish... that; (a) The Message is Authentic from the Client Machine and (b) The Message is Authentic from the Application.
Remember most Hacks are NOT going to be Packet Interception outside of a Website Trojan or such... for Games., you're more likely to have a Hack that does Memory Injection; taking advantage of Applications rarely using Protected or Virtual Memory anymore.
As such, you can come up with all the fancy Network Packet Protection you want; but someone will just write a hack so that the Client itself is being changed... so said messages will still end up "Authentic" and the App will be behaving incorrectly.

The best way around this is to have both Client and Host running in Parallel., essentially you want both regularly checking in to make sure they have the correct information; and this becomes more secure the more Clients on the System., because you can compare against them as well.

This as a note is partly why AppGameKit doesn't have "Built-in Security"... because the solution you need is going to be bespoke to your project and needs.
Of course., I don't believe for a second TGC thought like that, and it's more likely a case of providing "Bare Minimum" Features to be able to complete a Feature Checkbox.

•

Really to figure out what and how to approach Security., you'll need to figure out what kind of protection you want.
It's also BETTER to do it manually than via something like EASY Anti-Cheat., because a Bespoke Solution requires a Bespoke Hack to defeat; where-as Common Anti-Cheat approaches work on the basis of just stopping common approaches, which is fine for minor titles that no one cares about; but take something popular (say Fortnite) and well it ends up just being a way of saying "Look we're serious about stopping Cheaters" when in reality... they still exist as it's popular enough to warrant the effort to defeat it., and it's not massively hard to get around.
(Again by changing data in the Client, everything gets authenticated as A-OK)

•

Now as for the package length... well there's nothing stopping you sending Data as Multiple Packets; just remember you have to keep track of what's in each packet to put it all together the other end.
And as noted., AppGameKit doesn't use Threading; so for each Packet., you'll incur a latency hit.

This reminded me of those 'Hack' use in games like 'Maple Story', player was flying all over and even 'Vacuuming' mobs into their weapons...
A standard socket ssl connection would work as well as https...
Connection on both side is encrypted and yet able to be decrypted to be display by a browser...

Perhaps something like this from another, maybe better, game engine: https://www.youtube.com/watch?v=gcopx40pwvY

We can't use it in AppGameKit basic...
...And nothing here: https://www.appgamekit.com/documentation/Reference/HTTP.htm <- nothing here allow us to setup a https web server to listen for CreateHTTPConnection() from another agk client..

Is socket/udp any size data package?

All connections have the exact same MTU limitation.
But this said AES is always used for actual packet security... so 128bit (16Byte), 192bit (24Byte) or 256bit (32Byte)
Still a Block Size is always going to be 16Byte., so arguably you should always use 128b; and this still ends up secure provided you keep rotating the key every 3600s (5min)
There's a reason why SSL/Cookies have used this renewal time since 1998.

With this said., AppGameKit does have support for SSL within the HTTP Functions.
An Optional Input for the CreateHTTPConnection( ) is "Secure" meaning., is it a HTTPS / SSL Connection; another command SetHTTPVerifyCertificate( ) allows you to Enable / Disable SSL

In any case., the Dedicated Socket / UDP / TCP will not use Secure Socket Layers., instead Security is entirely based upon what YOU chose to implement (and how).
Now the way that this is described in the GoDot Video is in essence a Simplified version of how most MMO work (Gateway, Authentication and Game)., it's also how most Digital Service with a Global Account across Multiple Games will also tend to work.
Still for an Stand Alone Game... you don't really need to worry about such things., not unless you want to store and track unique user data.
Even then it's better to simply connect and use an existing Account System (i.e. Steam, Live, PSN, Origin, etc.)., as then you're just extending data with game specifics that you're storing as opposed to needing to worry about the security of Usernames, Passwords, Payment Information, etc.
Let the BIG BOYS worry about keeping that stuff secure.

Rather YOUR key objective should just be to ensure that people aren't overtly hacking, cheating, etc. i.e. trying to maintain a Fair and Level Playing Field, to ensure everyone is playing within the rules and has a chance to be awesome based on skills, rather than based on what scripts they were able to download.

And THAT kind of Security is very different to think about than simply keeping packet data secure.
As noted above., most of such things are coming from an Authenticated Client; so what you need to ensure is the Data the Server is getting and disseminating is also Authentic to the Game Rules.
How you approach that depends heavily on the game in question.

For example, if you don't want Wall Hacks (where you can see players wherever they are)., well only have the Server provide this information based upon potential visibility... i.e. if you're not going to SEE or HEAR said Player; don't share their Location with said Client.
You don't have players flying in the game... well don't share Positional Data., share Button Presses; have the Server work out where they should be to share that.
Same is true for aiming... just think of creative approaches where data can be correlated against what the Server expects to happen.

I mean it's why I tend to use a Seed Value for Servers that the Players all have; as then Physics works off of said seed., and thus on the same tick will have identical results.
Remember your Server is MORE than just a Connection to share data between clients; but even if it was; using something like a Common Seed, means all the Clients should have the same results from native inputs; thus if one is showing "Odd" behaviour., all the other Clients should be able to detect this and disregard false information.
You essentially can't stop people trying to cheat... but you can mitigate or reduce the impact it has on other peoples games.

Personally I like writing systems that make cheaters feel like they've gotten away with it., while quietly they get flagged and matched up with other cheaters.
A bit like security systems that don't stop people playing the game they've pirated; but DO make it much more difficult or throw in some bug that ONLY happens to said crackers... that way when they're crying about a level being unfair or unbeatable; well you know EXACTLY who has stolen it.

I mean I can't setup agk as a https server with custom signed cert...