Login/Handshake issues

[splitice]

I am unable to get this to work.

Tested on 1.2.x: Fails to get protocol version from handshake, persumes protocol is 0.

Tested on 1.3.2: End server responds that login is incorrect (which it is not). Something to do with the encryption?

[pdelvo]

1.2x Versions are currently not supported, because the Login proess is very different. I could add Support for it. My library supports them, but I thought it is now not Longer needed.

the Server must be in offline mode. It is techniccally not possible to put it in online mode. The Proxy Server checks the user accounts, so it is not a security risk if the backend Server is not accessable directly

[splitice]

Ah I saw it in the library, so I persumed it was a bug. Its still used by tekkit servers as they havent transitioned. Ive managed to get it to work on 1.3.2 in offline mode although one in every 10 logis still fails (on the proxy side). Would have been cool if it could pass through the authentication, then it could be seemless.

Love the way you implemented the plugin infastrucutre, so flexible. So beyond what I could implment :P Currently writing an entity cache plugin (great for when multiple people are connected over high latency links) might even extend it to do an optimistic block cache.

My aim of course being to make it possible for people in other contries to be able to connect to the server and within their own coutry / region proxy node have all player entities cached (generation of appropriate packets before the server does -- in an optimistic way before the server corrects).

Loving all the work you put in. Got a crude PoC written to get some interest from my mates now using mostly EntityTeleports to relocate. :)

Just a couple of quick recomendations: 1) Would have been great if in MinecraftLib the Entity packets all extended a base or had an interface that defined the common aspects (EntityID, Position etc) would save me soo many if statements (Only because I dont want to edit your code and loose future version support) 2) A list of ID => Packet class mappings would have been a nice include, ive found what I need but atleast one of them took me a little while (obvious once I found it though). 3) Yeah 1.2 support, if only for tekkit but I suppose give it a month and even they will update. But yeah dont destroy support for old versions when adding new. Perhaps a protocol version abstraction would work providing it didnt add too much extra work for you of course.

Thanks.

[pdelvo]

Thank you for your Response. I like your idea. Will you publish it open source? I would really like to see this.

To your questions:

1) You can fork the minecraft library Project, make These changes and send me a pull request. Im really busy this Weekend, because today is my birthday :) If dont want to do this I will do this next week, because it would be really practical.

2) It is a Little bit complicated, because this minecraft protocol library is built to Support many different Version at once. because of readability I use sometimes multiple packet handles for different Versions of a packet. So I dont have a Dictionary with just showing the handler. I have a dictionary which asociates a packet id to a list of possible handlers. I will add a public property to Access it. But also you can feel free to fork it and do it :)

3) It is not very easy but possible. I will do this next week too.

[splitice]

First of all happy birthday mate, have a good one. I look foward to seeing the changes, And as for doing the inheritence ill look into doing it for you I should have time on monday.

As to if Ill be open sourcing it, I am not sure at this point. If I do it will most likely still be something I plan to use semi-commerically with one of my projects but thats only if I ever get around to completeing a super polished version. TBH this is a project Ive wanted to do for almost a year and after having fiddled with other proxy layers decided not to, I only discovered this yesterday (through minecraftlib) and as like WOW... well it got much easier to complete anyway.

Maybe ill try and put it past my games programming lecturer as a possible HD project, if so Ill definately have a reason to finish it. :) Just added the ability for entities to move towards you and get a cache hit :) (as opposed as you moving to them)

Planned features:

• Entity Range restriction (independant of server vd for localized caching)
  • entities move in teleport in.
  • you move towards entities they teleport in (load from cache then correct)
  • cache invalidation for where player thinks entity is (entity frozen at 3,3,3 entity is actually over REMOVE_DISTANCE away then teleport to actual so as not to polute screen with stale data) same with removed entities.
  • applies to players too (really the most important part, player entity spam is a huge number of packets on huge servers)
• Send for one, send for all (time)
• Block cache (difference of cached -> server response sent via changed or if large enough a re-send, either way more responsive)
• Low packet rate detection, use to send wider entity packets
• Possibly: /proxy set VIEW_DISTANCE [num] and other commands for controlling how much bandwidth to allow through
• Local chat (still global, just pushed out locally before server response)
  • hard part will be identifying the message, messages that are the same etc. Probably need a hitlist.
  • Possibly: Region only chat (within the proxy node).
• Possibly: a minecraft plugin that computes doesnt send overlapping area within the same proxy node, save on CPU and bandwidth.

[splitice]

Also move and look packets instead of teleport when movement is small enough later on when I can be bothered writing it.