views:

1009

answers:

5

I am sending data to server twice. first i send "Hello world" then I send "Server". But server recieved the data at 1 read. but server have to read the data in two read operation.

Also I write the data then read data from server then I write the data In this case server can read the first data. but server can not read the second data server used read, write, read

So how to overcome this issue. how to write data to socket in blackberry

A: 

For the first query, I guess you are using TCP. If you use UDP, then the server will read the packets in the order you want.

Can you be more clear/elaborative on the second query ?

Satish
UDP order is not guaranteed. You can't depend on it.
chrish
quite offensive comment ))
Max Gontar
A: 

Hard to say without a little more detail, but it sounds like you're using 1-directional communication in the first case - i.e. the client writes, then writes again. There are any number of reasons that the server would receive the 2 writes as 1 read. Buffering on the client, somewhere in the wireless stack (or in the BES), buffering on the server side. All of those are legal with TCP/IP.

Without knowing anything more about your solution, have you thought about defining a small protocol - i.e. the client writes a known byte or bytes (like a 0 byte?) before sending the second write? Then the server can read, then recognize the delimiting byte, and say 'aha, this is now a different write from the client'?

Anthony Rizk
+1  A: 

What you describe is how TCP is supposed to work by default. What you are seeing is the Nagle algorithm (RFC 896) at work, reducing the number of outbound packets being sent so they are processed as efficiently as possible. You may be sending 2 packets in your code, but they are being transmitted together as 1 packet. Since TCP is a byte stream, the receiver should not be making any assumptions about how many packets it gets. You have to delimit your packet data in a higher-level protocol, and the receiver has to process data according to that protocol. It has to handle cases where multiple packets arrive in a single read, a single pakcet arriving in multiple reads, and everything in between, only processing packet data when they have been received in full, caching whatever is left over for subsequent reads to process when needed.

Remy Lebeau - TeamB
A: 

I would try explicitly telling Connector.open to open up the stream as read_write. Then I would ensure that I flush my connections after each time I talked to the server.

SocketConnection connection = (SocketConnection) Connector.open(url, Connector.READ_WRITE);
OutputStream out = connection.openOutputStream();
// ... write to server
out.flush()
beffbernard
A: 

As previously said this is an expected TCP behavior to save bandwidth. Note that to deliver your package TCP adds lot of data (e.g. destination port,sequence number, checksums...).

Instead of flushing the data I´ll recommend you to put more work in your protocol. For example you can define a header that contains the number of bytes to read and then the payload (the actual data).

The following code is a protocol encoded in an string with the structure [length];[data]

StringBuffer headerStr = new StringBuffer();
StringBuffer data = new StringBuffer();
//read header
char headerByte = dataInputStream.readChar();
while (headerByte != ';') {
  headerStr.append(headerByte);
  headerByte = dataInputStream.readChar();
}
//header has the number of character to read
int header= Integer.parseInt(headerStr.toString());
int bytesReaded = 1;
char dataByte = dataInputStream.readChar();
//we should read the number of characters indicated in the header
while (bytesReaded < header) {
 data.append(dataByte);
 dataByte = dataInputStream.readChar();
 bytesReaded++;
}
Dani Cricco