[1.7.10][Solved] Strange nullPointer when handling a packet (on the client)

[wesserboy]

For my current mod I need to process data on the client, and send the results back to the server. I am using a system of packets to achieve this, however, I'm not sure what's the best/most efficient way to achieve my goal.

 

The first time any client connects to a server, I will send a packet/packets containing the data I need that client to process. After its done I send the result(s) back to the server via another packet/other packets. On the server I will save these results and after that point no more packets will be sent.

 

As you can probably tell from the way I describe my problem I am not sure what's the most efficient way to achieve this.

 

This is where my question comes in: If you need to process (a lot) of data, is it better to send one big packet, containing all the data which has to be processed, and send a big packet back containing all the results, or is it better to send little packets which each contain a single piece of the data, and send little packets back containing the individual results?

 

my current code crashes every time I join a (new) world, I think this crash is related to my question because i am currently using a mix of big and little packets...

but if you need a (not yet working) piece of my code, i will happily supply it.

[Failender]

1. what type of data are we talking about? clients should not process data, because then they can fake the results..

2. one big packet is the best in my opinion, because theres really no sense in splitting those up

3. it wont crash because u use a mix of packets, itll crash if u mess sth up :b

[Failender]

in addition: if u are sending GB of data u are having serious problems :'D

[wesserboy]

1. what type of data are we talking about? clients should not process data, because then they can fake the results..

2. one big packet is the best in my opinion, because theres really no sense in splitting those up

3. it wont crash because u use a mix of packets, itll crash if u mess sth up :b

 

1. I need a list of all possible items on the server, to achieve this I'm iterating through the itemRegistry, and if an Item has subItems, i need to get those, otherwise i'm just adding a stack with damagevalue 1. the Item.getSubItems() method is ClientSide only, and this is why i need to process this data on the client.

 

2. This is what i needed to know, I am currently sending one big packet from the server to the client, and i am responding with a lot of little packets, but i will change this out to one big packet as well.

 

3. You are right . The crash is happening on the client when handeling the packet. It's a really strange nullPointer and i thought that data maybe got lost because i was using such big packets to the client. Since this is the way to go, this clearly doesn't cause my problems, and i will post more info about the crash in the next post, because i can't seem to figure out the cause myself...

[Failender]

1. why . forge is already kinda doing that  for you with just saying mods need to be on the same versions, or they get a connection refuse. I might be tripping with understanding you there

[wesserboy]

This is the code I am currently using for my packet from server to client:

https://gist.github.com/wesserboy/dc7f1f88afb3b83aaac6

(In this code i am still sending multiple small packets to the server, I am changing that as we speak, however this can not be related to the issue, since the code crashes before this is done)

 

This is the stackTrace of the nullPointer:

http://pastebin.com/cnGGaVuV

(from what i can tell it's the same crash happening three times in a row, that's why i've added spaces in between the three individual stackTraces)

 

Line 76 (The for loop in the handleClientSide() method) crashes with a nullPointer.

 

I started to trace this variable backwards (that's why there's a lot of System.out.println()) and this is what i found:

 

on line 74 (the beginning of the handleClientSide() method) the items field is null, this is obviously what causes the nullPointer.

However, on line 46 (the end of the fromBytes() method) the items field is not null...

 

I am not quite sure how packets work behind the scenes, but to my knowledge these methods should follow each other with no changes made in between...

Also, it seems very odd to me that a stackTrace refers to a package declaration... (line 4 of the stackTrace)

[wesserboy]

1. why . forge is already kinda doing that  for you with just saying mods need to be on the same versions, or they get a connection refuse. I might be tripping with understanding you there

 

My idea is to make a mod which assigns a random item to each player to acquire, to give the player something to work towards whilst playing.

I need to assign this itemStack on the server (for obvious reasons).

It would be silly if the mod would only ever assign bonemeal, instead of all possible dyes, and only oak wood instead of all types of planks/logs.

This is why i need to index the subItems of these items.

 

[wesserboy]

after a good night of rest i have figured it out...

It was an incredibly stupid mistake.

 

In my handleClientSide method I was using the field of the object handleClientSide was being called from, instead of the field of the message parameter. 

 

Moral of the story: Don't code if you're tired, it can only end badly...

[delpi]

Good for you.  Still at a loss for why you are sending all that to the client.

 

Decide your item on the server.  Send a chatmessage to the player or just send the one item they need to get.

[wesserboy]

Good for you.  Still at a loss for why you are sending all that to the client.

 

Decide your item on the server.  Send a chatmessage to the player or just send the one item they need to get.

 

This is what I am doing after the list is constructed, I only do this the first time any client joins, because i need a clientSide only method to construct the item list.

I store this list on the server and after that point any other clients joining will not get this packet.

[wesserboy]

One thing: Hacked clients. Your mod is a security hole the size of texas

 

I am not quite sure how hacked clients work and what exploits they are using to achieve what they're doing, but is there a way for me to make my mod more secure?

Maybe general rules to stick to? Or some kind of technique I am unfamiliar with?

Preferably something that doesn't involve me having to rewrite my list construction (again), unless it's really necessary...

[wesserboy]

As soon as you in any way trust the client you have a security hole. Your mod as you described it completely trusts the client in giving you all the subtypes of an Item. There is nothing stopping a client to tell you that Blocks.stone has an ItemStack of command block with NBT data on it as a subtype. Your mod would happily accept that and bam, people have control over the server without any sort of security mechanism stopping them.

 

I am checking if an item actually has subItems on the server (using item.getHasSubtypes(), which strangely enough isn't ClientSide only), before i add it to the list that is being sent to the client, and I have a blackList system in the config file, which gives servers more control over what items end up in the list, but other than that you are totally right...

 

I could maybe implement a system that checks whether the items of the ItemStacks were actually sent to the client, as an extra security measure.

 

However, I am not sure if it's worth the effort, I am only using this list of itemStacks to assign a 'ChallengeStack' to the player, the player should then try to acquire this itemStack.

I am checking this in the ItemPickupEvent, ItemCraftedEvent and ItemSmeltedEvent. If the itemStack the player picked up/crafted/smelted is equal to the assigned itemStack the player gets a message notifying him of completing the challenge, and a soundeffect starts playing. After that i just assign a new ItemStack as a new challenge.

 

Since I am never giving the player any of these itemStacks, never spawning them in the world and never placing blocks, I think the level of control the client gets is very little, which is why i don't think it's that big of a problem.

but if I missed something, be sure to tell me

[delpi]

Just get a list of all the items on the server (won't have sub), iterate through it, check for subtypes, append the list. 

 

No real need to go to the client for all that.

[wesserboy]

Just get a list of all the items on the server (won't have sub), iterate through it, check for subtypes, append the list. 

 

No real need to go to the client for all that.

 

ahh, I think I understand what you mean now, this will however not work:

You can get the boolean to know if an item has subtypes on the server, you can however not get those subtypes on the server, this is why I request those subtypes from the client.

 

This is another approach i thought of which is similar to yours, which also doesn't involve as much client data on the server:

- Create a list of all items on the server. (excl. subitems)

- Get a random item to assign.

- If the item has subitems, send it to the client --> let the client generate a random subItem and send it back to the server --> assign itemstack as challenge.

- else just make a new itemStack with damagevalue 0 and assign this to the player. (no client interaction at all)

 

This would not work as i would like it to and i will tell you why:

First you get a random item, if this item doesn't have subitems it's immediately assigned, so the chance to get that itemStack as a challenge is 1 / amount_of_items.

if it does have subItems, one subitem is randomized, so the chance of getting that itemStack as a challenge is (1 / amount_of_items) * (1 / amount_of_subItems) = 1 / (items * subItems).

 

This would make it so some itemStacks have a higher chance of being the challenge than others.

 

A way to fix this would be to add the items that have subItems once to the list for every subItem.

then the chance of getting a certain subItem would be subItems / items * subItems = 1 / items (the same as all the other items)

But as far as i know there is no way to get the amount of subitems an item has, and this makes it so this approach would not work (as intended).