server with NIO - sending data

[blahblahblahh]

@Kova

@blahblahblahh

1. wait till the next 50’th ms
2. register for WRITE
3. send
4. repeat until all sent
5. de-register for WRITE
6. … go and do other logic, then come back to 1. at the appropriate moment

How this solves puting send in same thread as read? You still have to sleep 50 ms in step 1 and miss incoming data. …or I’m the one who missed something?

a. get time.
b. …do reading stuff…
c. check how many millis left before need to do next write
d. sleep (that long)
e. go to step 2

Any why registering for write? Isn’t that a selector thing? Why not just write if channel is open?

OP_WRITE is the only way of knowing that the channel is ready for being written to, that is the definition of it. If you write when its not ready, then either you’ll get an exception (if you’re lucky), or you’ll write 0 bytes, or you’ll overflow your bytes and think you’ve written them but not actually managed to. Your network card and OS only have a limited capacity of outgoing bytes :).

[Kova]

@blahblahblahh

a. get time.
b. …do reading stuff…
c. check how many millis left before need to do next write
d. sleep (that long)
e. go to step 2

That means that data can arrive when I’m sleeping and max response time of reading the data can be 50ms. Kind of don’t like this approach… what if won’t need send data so often in future, like it could be 500ms. Then reading would be unnecesary slow. I’ll stick to multiple threads thing.

[quote=“blahblahblahh,post:21,topic:26484”]
tnx, good to know… although I kind of expected that OS or VM queues requests if it can’t fit it all. Like TCP, it makes sure you get the packet, but it takes time.

[Kova]

I finally deceided not to bother with the thing right now and focus on getting that single connection that works usable. I’ll come to this later when game will be in more completed stage.

[Kova]

more usefull stuff about writing to channel, I found this in www.codecomments.com:

[quote=“Thomas Hawtin, 2006-01-28, 3:57 am”]Keep your key registered with the selector throughout. However you need
not be interested in OP_WRITE until you find that you can’t write any
more. Just write your buffer out, and see if it fails to be copied out.
When the channel wont accept any more writes, only then do you need to
be notified when it is in a state for further writes.

Unless you have data that you can’t written at the moment, then there is
no need to be notified of when you can write data. Selecting with
OP_WRITE will immediately return until you fill the relevant system buffers.

Similarly if you couldn’t deal with reading any more data (because your
buffers are full, say), then you should not be interested in OP_READ. Or
if all your worker threads are tied up and you can’t take another
connection, don’t be interested in OP_ACCEPT.

As a rough approximation, you could write your code not to use OP_WRITE
at all (although it will obviously fail nastily when the relevant system
buffers fill up).
[/quote]

[blahblahblahh]

@Kova

That means that data can arrive when I’m sleeping and max response time of reading the data can be 50ms. Kind of don’t like this approach… what if won’t need send data so often in future, like it could be 500ms. Then reading would be unnecesary slow. I’ll stick to multiple threads thing.

Shrug. I don’t know what you’re doing, you haven’t really described it, so I’ll stop giving advice :).

[Kova]

nvm, I was just creating a thread that would send packets every x ms (not every christmas, but every x milisecs ). Anyway it took longer but I got it myself. All left is to handle unusual behavior and exceptions. Tnx everyone for their little something.