[Lib] PacketAPI - Next generation Packet Management [Questions]

Discussion in 'Resources' started by bigteddy98, Mar 26, 2014.

Thread Status:
Not open for further replies.
  1. Offline

    bigteddy98

    This resource is no longer available.
     
    Skyost, ase34, Goblom and 3 others like this.
  2. Offline

    DevRosemberg

    This is actually really nice. Keep up the good work Teddy!
     
  3. Offline

    Garris0n

    [​IMG]

    Why is it faster than ProtocolLib? Surely there's something ProtocolLib is doing that your plugin is not why you can get better performance, I highly doubt Comphenix would just make ProtocolLib needlessly inefficient.
     
  4. Offline

    Quantum64

    @Comphenix uses massive amounts of reflection to get packet classes, to remain compatible with every version of Minecraft. Not sure that would impact performance that much though.
     
  5. Offline

    xTrollxDudex

    Garris0n
    Comphenix uses a lot of functionality and NetworkManger intercepts plus netty connection listeners to get the packets. This just replaces the PlayerConnection of joining players, probably will not be functional in the future, may be finalized to prevent overrides. Basically, ProtocolLib would last a very long time compared to this.
     
    Garris0n likes this.
  6. Offline

    Garris0n

    Why would they do that, though?
     
  7. Offline

    xTrollxDudex

    Garris0n
    I don't know, but I do know various classes that have no reason to be finalized be declared final, such as the Explosion NMS class. It juuuust might. Bukkit probably doesn't want people messing around with connections so...
     
    Garris0n likes this.
  8. Offline

    ArthurMaker

    bigteddy98

    You are turning into a god. I like that :D
    Your resources are just awesome. Keep going with the great job!
     
    bigteddy98 likes this.
  9. Offline

    DSH105

    That graph also shows that ProtocolLib is more consistent in performance, whereas this library may only offer faster performance in general.
     
    glen3b, KingFaris11, Cirno and 3 others like this.
  10. Offline

    LazyLemons

    All this library/plugin does is replace the existing player connection class with a new one. This causes conflicts with other plugins that are doing the same thing, plus you have no support for inbound packets.

    Minecraft 1.7 gave us Netty, why don't you use that instead of using ugly hacks that were common back in the early days of Bukkit? No need to reinvent the wheel, especially if it's a less functional one.
     
  11. Offline

    bigteddy98

    True, but that's why it's a library, right? If multiple plugins could do this, I would have made a class for it.


    This is faster, and as long as the playerconnection won't be finalized, I will probebly keep it like this, but thanks.

    - BigTeddy98, Sander.
     
  12. Offline

    LazyLemons

    What is the selling point of your library over ProtocolLib, or even a plugin's own implementation? Do you think your library has enough benefits and features to have the same widespread use that ProtocolLib has?
     
  13. Offline

    bigteddy98

    The big difference between PacketAPI and ProtocolLib is that PacketAPI uses no reflection, ProtcolLib does. This causes everything to be just a bit different.

    Example ProtocolLib:
    Code:java
    1. PacketContainer fakeExplosion = protocolManager.createPacket(
    2. Packets.Server.EXPLOSION);
    3. fakeExplosion.getDoubles().
    4. write(0, player.getLocation().getX()).
    5. write(1, player.getLocation().getY()).
    6. write(2, player.getLocation().getZ());
    7. fakeExplosion.getFloat().
    8. write(0, 3.0F);
    9. protocolManager.sendServerPacket(player, fakeExplosion);


    Example PacketAPI:
    Code:java
    1. //create new packet instance with arguments: location, radius
    2. PacketWrapper wrapper = Packet.PacketPlayOutExplosion(loc, 3);
    3. //send the packet to a player
    4. wrapper.send(p);

    If I would have to choose between these two, I would personally choose mine.

    -BigTeddy98, Sander.
     
  14. Offline

    LazyLemons

    Comphenix does have a PacketWrapper repository available here, and, arguably, using it is just as easy, and documented.
    Code:java
    1. new WrapperPlayServerPlayerInfo() {
    2. {
    3. setOnline(true);
    4. setPing((short) 0);
    5. setPlayerName("potato");
    6. }
    7. }.sendPacket(player);


    As for your point, I feel that a good-looking front end, no matter how sexy it is, is nowhere near the importance of a functional backend, that your library lacks.
     
  15. For the sake of compatibility, I hope you're proxying the playerconnection right?

    Edit: Also why not just use netty? Netty is safer then your way, better then your way, is compatible with multiple plugins. I suggest you to take a look at tiny-protocol ( Comphenix has made it) and maybe consider updating your lib. It's all neat and stuff hacking into the protocol but you still need to asure safety, if you can't convince me that your library is 100% compatible with most of the plugins out there then I won't use it.
     
    DSH105 and bigteddy98 like this.
  16. Offline

    bigteddy98

    I just added Netty, thanks to everyone who told me there were better ways of doing this :).

    Git is updated. Bukkit Download is waiting for approval.
     
    CaptainBern likes this.
  17. bigteddy98 Looks like you forgot to override channelRead :p (allows you to capture incoming packets)
     
  18. Offline

    bigteddy98

    Did that on purpose, I really don't get why you should want to listen on incoming packets. Can you explain?
    //EDIT: Nevermind, added PacketRecieveEvent, thanks :)
     
  19. bigteddy98 One last thing, it's better to call the onPacketSending etc on the main thread (so users don't have to do that themself). Since netty/the channel is running on it's own thread (not the bukkit one) each bukkit call can cause trouble.
     
    bigteddy98 likes this.
  20. Offline

    bigteddy98

    Didn't know that, thanks man.
     
  21. Offline

    MasterGberry

    Funny thing is I was just investigating CPU usage on my server and found ProtocoLib to be hurting quite a bit...although I only use one type of packet and don't need to scan them all. Is there some way to configure this to only intercept certain types of packets nicely besides checking getPacketName()? Not sure how quick this is but if I can only scan the one type of packet it's bound to be faster than what ProtocoLib is doing now...I was kinda tempted to just hack an event into the NMS level for anytime a tab packet (showing player name + ping) is sent to intercept and handle it...since I only care about that one packet at the moment.
     
  22. Offline

    bigteddy98

    Not yet, but I am thinking of a possibility to specify the packet type in the annotation. Like @PacketHandler(type = PacketType.PacketPlayOutAnimation), what do you think? Is that what you're looking for?
     
  23. Offline

    MasterGberry


    Something like this would be good. I'm not sure if it would really help performance too much because I assume you are still capturing all packet input versus my idea of just hacking in the NMS a small event that fires off ONLY for the 1 specific packet I am interested in changing. Maybe the difference is so small it can't be detected, not really sure. What do you think in terms of performance? I am trying to max out a server to the absolute limit haha, so anything past 1% CPU usage on the server thread is not welcome on my server :p

    If the instanceof checks or whatever on your plugin are light weight enough then I would just use this instead of doing the NMS stuff myself. If you want some help testing this with your new type= stuff let me know and I'll be glad to give it a go. You can hit me up on Skype also if you want to talk about this in more detail, same username on Skype.
     
  24. Offline

    bigteddy98

    PacketAPI is now also using the netty handler, thanks for giving advise.
     
  25. Offline

    Comphenix

    I don't know the exact circumstances on your server, but if you're using ProtocolLib 3.0.1 - 3.20, you might see improved performance in 3.30-SNAPSHOT with CraftBukkit 1.7.2+. But I'd need to see your performance log to know for sure. It would also verify that you're not counting time spent in other plugin's packet listeners.

    Still - if you really want to trade compatibility and simplicity, you should consider using TinyProtocol (example plugin). That way, you CAN just do an instanceof check, and skip everything else. It will only use a small amount of reflection once per player during setup, but nothing at all while capturing packets. This is much faster than bigteddy98's approach, which uses Bukkit-style events and thus must call packet listeners with reflection.

    That's not entirely true. You may be able to avoid reflection when sending packets with one of your pre-defined static constructors, but you still use reflection in other areas:
    • Since you use Bukkit-events, all packet listeners registered by plugins must be called through reflection. But, unlike Bukkit, you scan the listener class for packet listeners every time a packet is intercepted. Looks like you fixed that on GitHub, but the method call is still done through reflection.
    • You have a generic PacketWrapper, like PacketContainer, that provides access to a packet through reflection (getValue() and setValue() in your case). So, plugins that intercept packets will have to use reflection to avoid referencing CraftBukkit, or access the underlying NMS packet instance like in ProtocolLib. There's also the fact that ProtocolLib uses dynamic recompilation to skip reflection in many cases, though this is limited to public fields.
    You should also reconsider the return type of getNMSPacket() - as it is now, any plugin that calls that method is bound to the versioned package net.minecraft.server.v1_7_R2.Packet. I think it's better to return an object, and let them cast it to the appropriate type (which could be different in the same plugin, if they use Maven modules). Also - keep in mind that your channel handleris invoking packet listeners in the Netty worker thread, and not the main thread. That means packet listeners must be thread safe, and avoid calling Bukkit API directly. You should at least document it.

    Also, you should post the source code for your benchmark online. I don't know exactly what you're measuring here (or even what packet you are sending), and I don't see why you'd combine the "first" and "second" test, when you usually discard the first couple of iterations to warm up the JVM (as code needs to be compiled the first time around). Writing benchmarks can be hard, and it's easy to measure the wrong thing.

    But, the biggest problem is that you're only measuring a small part of your plugin (that happens to be the fastest). Nor is packet sending a common bottleneck.
     
    glen3b, Garris0n, drtshock and 3 others like this.
  26. Offline

    bigteddy98

    Thanks a lot for the great advises you always have. I will have a look at the benchmark. I did the same tests multiple times and the result each time almost was the same.

    Thanks,
    - BigTeddy98, Sander.

    I made a new benchmark, multiple tests, all done under different circumstances. I also included the code I used to made this benchmark.

    HERE
    [​IMG]

    - BigTeddy98, Sander.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Jun 7, 2016
  27. Offline

    bigteddy98

    You might wanna take a look at the new graph I made:
    [​IMG]
    This also shows, ProtocolLib isn't that consistent as everyone thinks.
     
  28. Offline

    Cirno

    Just a bit curious; what code are you running to benchmark this? You have to remember to allow the VM to warmup just a bit; maybe send 10k packets from both and then running the actual benchmark.
     
  29. Offline

    bigteddy98

    The code is included in HERE, I am doing multiple tests for Java to warm up.
     
  30. Offline

    ArthurMaker

    I'm using it and I'm loving how easy it is. Incredible job, bigteddy98! Congratz.
    Note: I used to use ProtocolLib, but now, with PacketAPI, my RAM usage decreased a little...
     
Thread Status:
Not open for further replies.

Share This Page