Unexpected null or empty byte array

[chenjie19891104]

We used unity3d and smartfoxserver 2x to develop a war decision-making game.

Now we had a feature like this:

players need making a building，send the extension request with three params:a,b and c;

building has three type:x,y,z

now , problem occurs:

all things go well with type x and y, but error occured with type z;


all these type, client send the same params to the server. only the values of the params are different.

we now suspect that it's a bug of your client c# api, because it's ok when we used the java api.

1、though the error is throwed on server side, but we confirmed that the cause comed from the client

2、the error was not caused by application level code

so, I want to know, is anyone encounter the same problem and how to fix it.

the error stack:

18:28:42,402 ERROR [11742932@qtp-9624795-6] mortbay.log - /BlueBox/BlueBox.d
o
java.lang.IllegalArgumentException: Unexpected null or empty byte array!
at com.smartfoxserver.v2.protocol.SFSIoHandler.onDataRead(SFSIoHandler.j
ava:80)
at com.smartfoxserver.v2.bluebox.BlueBox.doPost(BlueBox.java:138)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511
)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1221)
at com.smartfoxserver.v2.bluebox.SessionFilter.doFilter(SessionFilter.ja
va:141)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1212)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:3
99)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.jav
a:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:1
82)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:7
66)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)

at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHand
lerCollection.java:230)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.
java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:1
52)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:54
2)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnectio
n.java:945)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.ja
va:410)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.j

[Lapo]

It might depend on the Base64 encoding when the client is connected in HTTP tunnel mode. There are many variants of this encoding and we've noticed that at times they have problems talking to each others.
We have seen this problem mainly with iOS, but in theory it could be possible under Unity as well.

Is there any chance that you can let us know what request did cause the problem? It would help a lot.

thanks

[chenjie19891104]

OK! Here is the exact code we used:

Code: Select all

public void CreateBuild(int fiefID,int boxID,int itemID,int[] heroIds){
		string cmd = "CreateBuilding";
		SFSObject obj = new SFSObject();
		obj.PutInt("fieldID",fiefID);
		obj.PutInt("buildingIndex_InField",boxID);
		obj.PutInt("itemID",itemID);
		obj.PutIntArray("heroIds",heroIds);
		fox.Send(new ExtensionRequest(cmd,obj));
}

the only diference is the value of the params. So the problem is caused by base64 encoding in sfs2x? How to fix it?

[Lapo]

It's not much that the Base64 algorithm in SFS2X is bugged, in fact it isn't.
The problem is that the Base64 specifications allow for a large number of variations that might end up slightly incompatible between themselves. For example a Base64 library for iOS could use a variation of the encoding that might not be compatible with the one used server side.

The problem is that this is not evident until a certain conditions cause the problem, and it may take a lot of time for us to discover it, in fact we have recently realized this by porting the API to a new environment, by accident.

You can see here that the number of variations is pretty big:
https://en.wikipedia.org/wiki/Base64#Va ... mary_table

We're now looking into a possible solution.