Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / September 2006

Tip: Looking for answers? Try searching our database.

Sending number - it makes no sense!

Thread view: 
logiclips@yahoo.com - 26 Sep 2006 14:02 GMT
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
Crouchinho - 26 Sep 2006 14:48 GMT
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?
logiclips@yahoo.com - 26 Sep 2006 15:17 GMT
Crouchinho schrieb:

> 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.
Crouchinho - 26 Sep 2006 18:49 GMT
> Crouchinho schrieb:
>
[quoted text clipped - 10 lines]
> 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.
opalpa@gmail.com opalinski from opalpaweb - 26 Sep 2006 14:58 GMT
> 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.

I see you send packetSize
> dos.writeInt(packetSize);

I do not see you send numPackets

Opalinski
opalpa@gmail.com
http://www.geocities.com/opalpaweb/
logiclips@yahoo.com - 26 Sep 2006 15:10 GMT
opalpa@gmail.com opalinski from opalpaweb schrieb:

> > 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
[quoted text clipped - 4 lines]
>
> 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.
opalpa@gmail.com opalinski from opalpaweb - 26 Sep 2006 15:38 GMT
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
opalpa@gmail.com
http://www.geocities.com/opalpaweb/
logiclips@yahoo.com - 26 Sep 2006 16:02 GMT
opalpa@gmail.com opalinski from opalpaweb schrieb:

> Here are the steps I would take:
>
[quoted text clipped - 13 lines]
> 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?
opalpa@gmail.com opalinski from opalpaweb - 26 Sep 2006 16:54 GMT
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?
logiclips@yahoo.com - 26 Sep 2006 17:06 GMT
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.
opalpa@gmail.com opalinski from opalpaweb - 26 Sep 2006 17:32 GMT
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
opalpa@gmail.com
http://www.geocities.com/opalpaweb/
logiclips@yahoo.com - 26 Sep 2006 17:46 GMT
opalpa@gmail.com opalinski from opalpaweb schrieb:

> 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.


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.