Sending number - it makes no sense!

L

logiclips

Hi,

I'm sending data between a cell-phone and a PC via Bluetooth:

This works for strings and numbers when I explicitly set them (e.g. int
sendData = 3), but when I want to send data which is computed in the
follwing way, it doesn't work properly:

/* CLIENT */
// rawData.length is between 100.000- 2.000.000
int packetSize = 256;
int numPackets = (int)(rawData.length / packetSize);
byte[] packet = new byte[packetSize];
// write number of packets
ByteArrayOutputStream baos = new ByteArrayOutputStream();
DataOutputStream dos = new DataOutputStream(baos);
dos.writeInt(packetSize);
byte[] rawNumPackets = baos.toByteArray(); //write 4 byte
//send number of packets
connection.send(rawNumPackets);

/* SERVER */
byte[] rawNumPackets = new byte[4];
int length = connection.receive(rawNumPackets);
ByteArrayInputStream bais = new ByteArrayInputStream(rawNumPackets);
DataInputStream dis = new DataInputStream(bais);
int numPackets = dis.readInt();

So, the problem is the following:
When I compute on client side the value numPackets and print it out I
get an value of 542. This int value I send to my server, but here I
receive 434.
When I put on client side int numPackets = 542, then I receive on
server side 542.
This happens with every number.
That makes completely no sense to me!
Does anyone know what the reason for this could be?

Thanks,

Peter
 
C

Crouchinho

I've done something similar but over the internet with the datainputstream
readint() method and it sometimes gives a wrong int value. It worked on the
emulator everytime. I've checked whether it's a big endian or signed problem
but couldn't solve it. Please post if you work it out. By the way what's the
content of the bytes after the count?
 
L

logiclips

I see you send packetSize

I do not see you send numPackets

Oh, that's right. Actually I'm sending numPackets. I tried to send
packetSize once (that works) and forgot to change it back. Sorry.
In my code I'm sending numPackets and I've still the problem.
 
L

logiclips

Crouchinho said:
I've done something similar but over the internet with the datainputstream
readint() method and it sometimes gives a wrong int value. It worked on the
emulator everytime. I've checked whether it's a big endian or signed problem
but couldn't solve it. Please post if you work it out. By the way what's the
content of the bytes after the count?

I don't know exactly what you mean? The content of the rawData? These
are multiple images put in one byte buffer.
 
O

opalpa

Here are the steps I would take:

A) Verify nearly every step

for example does the byte array really have four elements?

B) flush all output streams

C) print out byte values on client ans server side for visual
verification of each byte being same


Also are you working in a threaded environment? Do you need to
synchronize?

Finally I hear cell phone technology is not quite ... reliable in all
circumstances. Perhaps there is some information on the web
http://www.j2mepolish.org/devices-overview.html about your device.

Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/
 
L

logiclips

Here are the steps I would take:

A) Verify nearly every step

for example does the byte array really have four elements?

B) flush all output streams

C) print out byte values on client ans server side for visual
verification of each byte being same


Also are you working in a threaded environment? Do you need to
synchronize?

Finally I hear cell phone technology is not quite ... reliable in all
circumstances. Perhaps there is some information on the web
http://www.j2mepolish.org/devices-overview.html about your device.

Thanks for the hints.
I figured out the following:

When I'm sending e.g. 436 I receive nothing

When I start sending again, e.g. 634 I receive 436
When I send then 723 I receive 634

So curiously, it receives the data which was send a round before.

Cann someone explain me that? What's wrong?
 
O

opalpa

That's improvement. Probably not much time to track down the problem
now.

In client when you

connection.send(rawNumPackets);

what is the type (the class) of connection?

In server when you receive, what is the type?
 
L

logiclips

On client side one creates an connection like this (class:
L2CAPConnection):
connection = (L2CAPConnection) Connector.open(serverURL);

On Server side (for waiting for connections) it looks like this:
connection = (L2CAPConnection)notifier.acceptAndOpen();

So both have the same type.
 
O

opalpa

Since L2CAPConnection.receive blocks:

by saying "When I'm sending e.g. 436 I receive nothing " you mean that
server blocks in receive?

and not that receive gives you 0 bytes, correct?

What happens when you call ready?


-----


Perhaps, worst case, you need to work around some kind of lack of
flush. That is if data on client is not being released until next data
packet is ready you can make a protocol out of that, as long as the
behaviour is reliable.

Can you try another phone to see what happens?


----


Cheers

Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/
 
L

logiclips

Since L2CAPConnection.receive blocks:

by saying "When I'm sending e.g. 436 I receive nothing " you mean that
server blocks in receive?

and not that receive gives you 0 bytes, correct?

When I first connect I receive 0 bytes. I don't know why.
What happens when you call ready?

When I call ready on client side for the first time it returns true and
stays true. When I call it one the server side it returns false the
first time then true.
-----


Perhaps, worst case, you need to work around some kind of lack of
flush. That is if data on client is not being released until next data
packet is ready you can make a protocol out of that, as long as the
behaviour is reliable.

Exactly, this would be the worst case...
Can you try another phone to see what happens?

Not at this time.
 
C

Crouchinho

I don't know exactly what you mean? The content of the rawData? These
are multiple images put in one byte buffer.

I used images as well (jpegs). They where somehow interfering with the
ints - maybe a little/big endian thing and the way bytes are read - but I'm
not sure.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,995
Messages
2,570,236
Members
46,822
Latest member
israfaceZa

Latest Threads

Top