Time |
S |
Nick |
Message |
05:01 |
|
|
nanoz joined ##friendlyjava |
05:26 |
|
|
aditsu joined ##friendlyjava |
06:33 |
|
|
nanoz joined ##friendlyjava |
07:03 |
|
mr_lou |
aditsu, So it would appear that J2ME MIDP does not have a Naggle Algoritm I can disable. |
07:04 |
|
mr_lou |
Gotta experiment with datagrams. |
07:04 |
|
mr_lou |
So.. because packets may get lots, I'm thinking I'll just constantly send the current status of my gamepad. This status can be represented with 1 byte. |
07:05 |
|
mr_lou |
Silly question: Should I worry about cluttering up the network? I can't quite see how that should be possible, when only sendting a single byte each loop.... |
08:19 |
|
aditsu |
mr_lou: I guess it depends how many times you're sending it per second; also, each packet has a header, so it's not just 1 byte in practice |
08:22 |
|
aditsu |
you should also try to see if the packet loss is significant or not; with a stable connection that's not overloaded, there should be practically no loss |
08:29 |
|
mr_lou |
Yes, I read somewhere that the DataGram header is 8 bytes. |
08:29 |
|
mr_lou |
vs 20 for TCP |
08:30 |
|
mr_lou |
Packet loss will be different depending on where the gamepad is used. |
08:31 |
|
aditsu |
IP header is also 20 bytes |
08:31 |
|
mr_lou |
oh |
08:31 |
|
aditsu |
TCP can be longer, but at least 20 |
08:33 |
|
aditsu |
it's not much, but if your actual data is 1 byte, it counts |
08:36 |
|
mr_lou |
1 byte to represent the state of the gamepad. Directions and buttons currently held. |
08:37 |
|
mr_lou |
I *could* choose to only send data when a change has been made. But then I have to include some check to see if a packet was lost. E.g. by adding numbers to each packet. |
08:38 |
|
mr_lou |
Would most likely result in much less trafic. |
08:38 |
|
aditsu |
ah, IP header can also be larger, but it's normally 20 |
08:40 |
|
aditsu |
or you could repeat each packet a fixed number of times to decrease the probability of loss |
08:41 |
|
mr_lou |
Would be nice to know what other wifi gamepads does. |
08:42 |
|
aditsu |
if you have one, you can try to sniff it |
08:45 |
|
mr_lou |
I don't. But there are many available for Android. |
08:46 |
|
aditsu |
or find open-source software for it and take a look |
08:47 |
|
mr_lou |
:-) |
09:03 |
|
aditsu |
there's also another protocol SCTP that combines some features of TCP and UDP, but in java it's only supported since version 7 |
09:03 |
|
mr_lou |
k |
09:05 |
|
mr_lou |
Evolution stops with me. I stick to old stuff. |
09:05 |
|
mr_lou |
:-) |
13:48 |
|
|
mr_lou joined ##friendlyjava |
14:31 |
|
|
nanoz joined ##friendlyjava |
17:42 |
|
|
nanoz joined ##friendlyjava |
18:13 |
|
mr_lou |
aditsu, If I'm only sending a byte, shouldn't I be able to receive it with datagram.getData()[0]; ? |
18:14 |
|
mr_lou |
datagram.getLength() returns 1. |
18:14 |
|
mr_lou |
So something is there... except it's always 0. |
18:14 |
|
aditsu |
what's the type of datagram? |
18:17 |
|
mr_lou |
Oh... nevermind... seems to be on the client. |
18:17 |
|
mr_lou |
Type? |
18:17 |
|
mr_lou |
Are there more than one type? :-) |
18:17 |
|
aditsu |
java class |
18:17 |
|
mr_lou |
Oh. |
18:18 |
|
mr_lou |
javax.microedition.io.DataGram. |
18:18 |
|
mr_lou |
But I spotted an error in the client. |
18:18 |
|
mr_lou |
It's sending 0... so.... makes sense. |
18:18 |
|
aditsu |
yeah.. I know nothing about that package :p |
18:20 |
|
* aditsu |
is trying to customize his Eclipse (adding a menu) and failing miserably |
18:20 |
|
mr_lou |
:-) |
18:21 |
|
mr_lou |
Good to know I'm not the only failure. |
18:30 |
|
* nanoz |
currently not into java |
18:42 |
|
mr_lou |
Apparently I can't even figure out normal bit operators anymore. |
18:42 |
|
mr_lou |
I don't see anything wrong, but it's just not working. |
18:42 |
|
mr_lou |
omg I'm stupid |
19:03 |
|
mr_lou |
yay |
19:03 |
|
mr_lou |
Finally |
19:03 |
|
mr_lou |
Now datagrams instead of socket. doesn't appear to be any faster though. |