Research in Moronity
-
Correct me if I'm wrong, but if the docs say I/O is blocking,
http://www.blackberry.com/developers/docs/4.5.0api/javax/microedition/io/SocketConnection.html
then wouldn't you expect a write to block if the buffer is full, rather than SILENTLY DROPPING YOUR DATA ON THE FLOOR WITHOUT TELLING YOU?
ARRRRRRGH.
And the expert opinion on their forums is "When you give up HTTP you have to do your own handshaking":
http://rim.lithium.com/rim/board/message?board.id=java_dev&view=by_date_ascending&message.id=6188 (second post)
So remind me what's the point of TCP again?
(And for further Blackberry WTFiness try writing 0 bytes to a socket and see what happens.)
(But it has such pretty icons, it must be good!)
-
Out of curiosity, are you doing your I/O on a separate thread? Having done BB development before, I can assure you that doing any I/O operation within the UI/event thread causes all kinds of bad things to happen, and all I/O MUST be done on a separate thread.
EDIT: By the way, the person on that forum who said you had to do your own handshaking was NOT an "expert", he was a just a regular forum user. Therefore, his opinions should be taken with a grain of salt. TCP/IP on the Blackberry isn't any different than what you'd expect.
-
@joeshmo21 said:
Yup. The threading in this particular bit of code is a barrel of WTFs all of its own. But it's definitely running in its own thread.Out of curiosity, are you doing your I/O on a separate thread?
@joeshmo21 said:
TCP/IP on the Blackberry isn't any different than what you'd expect.
Well, except that I'd expect to be told how much of my data got written, or to be blocked until it could all fit, not to have it randomly thrown away by the stack without any sort of indication that things might not have gone smoothly.
And that I'd expect to be able to write 0 bytes to a socket, and have the stack silently do nothing, rather than throw an exception.
And that I'd expect sockets not to randomly freeze up and stop transferring data at awkward moments.
Maybe my standards are too high.
-
My favorite Blackberry bug is that turning off the obnoxious Bluetooth activity indicator LED results in frequent dropping of Bluetooth connections, or random disabling of Bluetooth altogether. I blame Canada.
-
Why would you expect writing zero bytes to a socket to silently do nothing?
POSIX explicitly tells you not to do this: "If nbyte is zero and the file is not a regular file, the results are unspecified."
http://www.opengroup.org/onlinepubs/000095399/functions/write.html
And you're losing packets because TCP does not preserve message boundaries. There is no requirement that each send operation result in one packet being sent. A single send operation can result in two packets being sent and two send operations can result in one packet being sent. TCP is a byte-stream protocol. (If you mean that the received byte stream did not match the sent byte stream, you did a very poor job of saying so.)
-
@bstorer said:
My favorite Blackberry bug is that turning off the obnoxious Bluetooth activity indicator LED results in frequent dropping of Bluetooth connections, or random disabling of Bluetooth altogether. I blame Canada.
LED indicator lights are an essential part of any electronic device sold in Canada. They can be used to temporarily stun moose allowing you time to sneak up and club them to death with a hockey stick.
-
@joelkatz said:
Why would you expect writing zero bytes to a socket to silently do nothing?
http://java.sun.com/j2se/1.5.0/docs/api/java/io/OutputStream.html
public void write(byte[] b,
int off,
int len)
throws IOException"The
writemethod ofOutputStreamcalls the write method of one argument on each of the bytes to be written out"So calling it with len = 0 should be equivalent to calling the one-byte write method 0 times, ie doing nothing.
@joelkatz said:And you're losing packets because TCP does not preserve message boundaries. There is no requirement that each send operation result in one packet being sent. A single send operation can result in two packets being sent and two send operations can result in one packet being sent. TCP is a byte-stream protocol.
Could you please quote the part of my post where I said I was losing packets? I've just re-read what I wrote and can't see that anywhere.
Of course it's reasonable to assume that a complete stranger you've only just met on a forum probably doesn't know what they're talking about, because nine times out of ten you'll be completely correct. But believe me, I know what a byte stream protocol is, because I've had to pound this one into enough thick skulls myself during my time as a programmer.
Got a Blackberry JDE handy? Try this:
import java.io.*;
import javax.microedition.io.*;
class Main extends Thread
{
public static void main(String[] args)
{
Main obj = new Main();
obj.start();
}
public void run()
{
SocketConnection sc;
String url = "socket://192.168.5.10:12345;deviceside=true";
InputStream is;
OutputStream os;
OutputStreamWriter osw;
try
{
sc = (SocketConnection) Connector.open(url);
is = sc.openInputStream();
os = sc.openOutputStream();
test(os);
}
catch(Exception e)
{
System.out.println("Exception: "+e);
}
}
public void test(OutputStream os)
{
byte b = 0x00;
for (int i=6000;i<8000;i++)
{
System.out.println("Size is " + i + "\n");
byte buf[] = new byte[i];
for (int j=0;j<i;j++)
buf[j] = b;
try
{
os.write(buf);
b++;
}
catch(java.io.IOException e)
{
System.out.println("IOException: "+e);
}
}
}
}
See how it writes byte values that increase by 1 at each step? Point it at something like "nc -l -p 12345 | xxd" as the listener. Here's a sample of what I get after it's been running for a few seconds:004fed0: bfbf bfbf bfbf bfbf bfbf bfbf bfbf bfbf ................
004fee0: bfbf bfbf bfbf bfbf bfbf bfbf bfbf bfbf ................
004fef0: bfbf bfbf bfbf bfbf c9c9 c9c9 c9c9 c9c9 ................
004ff00: c9c9 c9c9 c9c9 c9c9 c9c9 c9c9 c9c9 c9c9 ................
004ff10: c9c9 c9c9 c9c9 c9c9 c9c9 c9c9 c9c9 c9c9 ................
004ff20: c9c9 c9c9 c9c9 c9c9 c9c9 c9c9 c9c9 c9c9 ................Where did bytes 0xc0 to 0xc8 go?
-
@joelkatz said:Why would you expect writing zero bytes to a socket to silently do nothing?
POSIX explicitly tells you not to do this: "If nbyte is zero and the file is not a regular file, the results are unspecified."
http://www.opengroup.org/onlinepubs/000095399/functions/write.html
And you're losing packets because TCP does not preserve message boundaries. There is no requirement that each send operation result in one packet being sent. A single send operation can result in two packets being sent and two send operations can result in one packet being sent. TCP is a byte-stream protocol. (If you mean that the received byte stream did not match the sent byte stream, you did a very poor job of saying so.)
What the Hell does POSIX have to do with Java on BlackBerry?
And why would anyone complain about having [i]their[/i] data being silently dropped unless the received byte stream failed to match the sent byte stream? I think that "the received byte stream did not match the sent byte stream" is fairly obvious from what he wrote. I certainly didn't think he was complaining about TCP/IP packet merging.
-
@joelkatz said:
(If you mean that the received byte stream did not match the sent byte stream, you did a very poor job of saying so.)
Nice post-edit.
-
@Wrongfellow said:
That whole paragraph (after the URL, confusing TCP streams with IP packets, and OSI level 7 stuff) was an edit..@joelkatz said:
(If you mean that the received byte stream did not match the sent byte stream, you did a very poor job of saying so.)
Nice post-edit.
-
BBOS is full of WTFs. Try installing a J2ME applet that uses data store, then immediately deleting it. [i]The entire OS needs to reboot in order to uninstall the app.[/i] You never ran the app, it never created a data store, but because it says data store in the descriptor, the OS feels the need to completely reset itself, which mind you, takes about five minutes.
I've had the displeasure of testing a J2ME+MMAPI app on a BB Pearl. Every time I changed the code and uploaded it to the phone for testing, I had to sit there and stare at an hourglass for five minutes while the phone went through its painfully slow reboot process. If only there was a simulator with a meaningful MMAPI implementation...
