Error requesting next task from server. about regex HOT 10 CLOSED

I found this bug a while ago, and am still fixing it. Sadly I didn't have any time to work on the code, so it'll take a while. Basically it's a problem when requesting too many tasks via the established connection, but the protocol expecting other input.

I usually provoke this error by manually requesting a new task, so if you could find some other behavioral pattern that creates that popup, please tell me.

from regex.

[...] when requesting too many tasks via the established connection

Does that mean the connection stays alive the whole time? Perhaps it needs some kind of periodic ping to keep it alive? Or maybe it would be better to connect, request a task and disconnect (I don't know how much overhead there would be)?

[...] if you could find some other behavioral pattern that creates that popup

Well for example I just opened the app and it happened. Opened the settings, closed them, and it suddenly worked. Tried to request another task and the bug happened. Opening and closing the settings now does nothing again, bug persists... It does seem so random :(

from regex.

Does that mean the connection stays alive the whole time?

Yes.

Perhaps it needs some kind of periodic ping to keep it alive? Or maybe it would be better to connect, request a task and disconnect (I don't know how much overhead there would be)?

Well if a connection fails, it should just recreate a new connection. The reason I designed the protocol to work like this, was to try and prevent spaming. The idea was, that you'll only receive the next task, after solving the current one.

Well for example I just opened the app and it happened.

Was the app running in the background before opening it? If so, ReGeX might have tried using a old connection (?)

Opened the settings, closed them, and it suddenly worked.

That restarts the game generator, and creates a new connection, explaining why it started working again.

Tried to request another task and the bug happened.

Yeah, the protocol expected something different. Maybe the best solution would just be to disable manual task requests for REDB.

Opening and closing the settings now does nothing again, bug persists... It does seem so random :(

That's weird. Could you create and send me a log? Does restarting (as in making sure it's killed in the task manager) help?

from regex.

[...], was to try and prevent spaming.

One can still spam by sending a lot of packets with a connection alive! It's hard to prevent that. You can really just trust your users IMO. This however doesn't stop you from making some temporary ban system.

[...] you'll only receive the next task, after solving the current one.

Actually though, can't you just skip your task and receive the next one?

Was the app running in the background before opening it?

It wasn't under Recent apps, so I doubt so.

Yeah, the protocol expected something different.

I don't know how the current protocol works, but I can't help but think about Telegram and their protocol. Basically you create a key and use it to encrypt the packets you send. The packets contain an ID, which simply is like a function ID (i.e. "send this message to an user" may be ID 0xf048b18a), and the server returns another packet, with an object ID (i.e. "message sent, these are the latest updates: ..."). I like their implementation, shall this serve as inspiration!

Could you create and send me a log?

What shall the log include? Simply the verbose output?

Does restarting (as in making sure it's killed in the task manager) help?

I forcibly closed the application from Settings and then opened it again. No success.

from regex.

Here is the log, with all the steps to reproduce.

Could you create and send me a log?

However there barely is any information from the bug (nothing comes in the log cat when it couldn't retrieve the task from the server). It's like a silent bug. Or maybe even a ninja bug.

Edit: I just tried adding the REDB server (I was connected to the network) on a fresh debug install and another bug appeared.

from regex.

If I solve a task, the thrown exception is the one below if (notifier.take() != ANSWR). Asking for another request after this is exception is thrown results in a never-ending request loading.

If I skip the problem, the one thrown is the one below if (notifier.take() != INPUT).

I don't know where I should look for the error so I'm simply providing all the information I can think of!

from regex.

One can still spam by sending a lot of packets with a connection alive! It's hard to prevent that. You can really just trust your users IMO.

Sorry for not clarifying, I was just referring to content spam, as in suggesting one solution over and over again. That's prevented by forcing the user to immediately solve the specific task that was just generated.

This however doesn't stop you from making some temporary ban system.

That's also planned, and is in fact partially implemented (If someone suggests a wrong solution, the servers just waits longer until next task is served). However the problem would be how to differ between connections being interrupted for no reason, and actual spaming.

Actually though, can't you just skip your task and receive the next one?

No, not currently. The protocol could be extended to interpret special characters (^C?), as "skip this round", but I fear that could lead to simple database spamming (just using yes to generate this command, and piping it through nc to the server for example).

I don't know how the current protocol works, [...]

It's defined here, and is pretty simple. Much simpler than the telegram example you brought up ^^. You can try it out manually with this command: nc redb.org.uk 25921, in case you're interested. Theoretically, there could be a network problem too...

I don't know where I should look for the error so I'm simply providing all the information I can think of!

Thanks, I'll take a look at it as soon as possible. I'm just a bit preoccupied with other stuff now, but it's up there on my priority list.

from regex.

With some Log.d debugging, I found out (or rather remembered), that the server was set up to take "a bit longer", if no or wrong answers are supplied (see here).

So 2d4edf5 changes:

• If conn.requestTask, fails at first (at any of the two points of failure you mentioned), ReGeX generates a new connection and tries again. If it still fails, the problem is reported as done until now.

• notifier.take is replaced with notifier.poll, meaning that ReGeX will wait for at least 5 seconds for a reply. If nothing happens, it reports an error (5s or more are pretty serious, so something has gone more wrong than it should have).

from regex.

I hate to disappoint and also to create so many issues which may seem too many (at least from my point of view), so sorry in advance!

However, I think that #31 didn't occur before (IndexOutOfBoundsException when opening the application). Again, sorry!

Regarding this issue, I solved one task and the next one seemed so hard, so I held the R button on the left of the EditText to load a different one. After a while… couldn't retrieve task from server >.< — but I'm curious: if this fix works for you, then I feel a bit less guilty :P

from regex.

Don't worry about reporting issues, the more the merrier (especially after they have been solved ^^). And someone would report it anyway, so it's better to have the opportunity to solve them as quickly as possible.

But I don't think that 2d4edf5 is to blame for #31. The commit changes nothing close to the line 228. From my perspective, this seems to have more in common with #29 and #27, but I'm not sure yet.

from regex.