Hi guys,
I’m developing an mmorpg and I’m using kryonet. My question is: Are these instruction
connection.sendTCP(message);
or
server.sendToAllTCP(message);
going to slow my logic thread if inserted in my main logic thread? If, for example, a lot of data has to be sent, is this operation going to run on the logic thread (slowing it) or on a different thread?
Sorry for my English guys ç_ç
Kryonet afaik serializes and sends on its own thread.
EDIT:
Technically you shouldn’t be sending packets every loop iteration. So yeah, technically it would slow down and even possibly lockup your game (If the TCP packet sends and does not ping back).
Try and limit sending packets and only send them when required, so maybe send UDP packets to each client every few frames for updates and TCP for everything else. Not good on the networking side myself so take this with a grain of salt.
Not sure exactly how Kryonet works as I’ve never used it only read about it, but regardless of how it works…
NEVER, NEVER, NEVER, NEVER, NEVER, NEVER HANDLE YOUR NETWORK ON THE SAME THREAD AS YOUR GAME.
Why not? Worked fine in Quake3 
well, have to disagree.
always always always always process network on the game thread if offloading it to another thread would be more expensive. just use a profiler and your brain = win.
also always know what thread you’re sitting on.
Do you mean process network data or IO? A profiler is pretty useless for IO! You’re basically doing soft real-time programming, and the issue there is dealing with worst case execution time. If the IO process may block for an unknown amount of time, then off-load it to another thread, though if @Gibbo3771 is correct this is already handled in Kryonet. OTOH, if you’re talking processing the data for IO, then I’d probably agree with you.
i ment network data and NIO.
quake 3 uses [icode]select[/icode], what is pretty much what NIO sockets do (http://docs.oracle.com/javase/7/docs/api/java/nio/channels/Selector.html#select()), what is what kryonet is using.
now, if you use NIO and process data on the same thread, it will be the select-thread which is the IO thread. so even then, if processing the data is faster then offloading the data, do not offload. that is for receiving data.
for sending data, its a bit different. writing into a SocketChannel is threadsafe. so you’re safe to use any thread you want to send data. you have three options :
option 2 and 3 is basically offloading.
if it would be based on old school IO, not NIO, using the game-thread would freeze the VM in no time.
edit
kryonet uses OP_WRITE keys for sending by default. writing will never happen on the game thread, just message-serialization - which is not expensive. to answer the initial question : no, IO will not slow down your “logic” thread. kryonet handles offloading data to another thread for us.
it is also using the selector thread for deserialization and notification (reading). so if we use a listener to process network data without moving to another thread, it can stall the server/client. keep in mind that the game-state, if changed, should be threadsafe then. kryonet does not help us with that.
I wasn’t talking about java.io vs nio
I meant in general you need to know whether the code you’re calling can have unbounded execution time. IO is one thing among many to be wary of.
Bearing in mind that NIO is blocking by default 
What I’m saying is that you need to know what you’re using - the OP’s case is probably fine, while saying
is (IMO) not.
is (IMO) not.
[/quote]
that’s not what i said 
if offloading it to another thread would be more expensive. :point:
… which is as oversimplified as
which is also false if not explained.
ofc we’d have to deal with timeouts and possible stalls if we’d send directly from the game-thread, it’s just not wrong to do so, generally.
No, if it might block offload to a different thread. There is no way to measure the expense of that because there may not even be one where you’re profiling it.
I agree with you the “never, never” post is false if not explained.
Well, of course, if you’re happy with the thing freezing for a few seconds, you should have said …
aye 