Проблема с использованием SocketConnection с Blackberry с использованием MDS - PullRequest
Новая
       33

Проблема с использованием SocketConnection с Blackberry с использованием MDS

5 голосов
/ 21 августа 2009

В настоящее время я пишу приложение для Blackberry для простой отправки и получения некоторых необработанных данных на другое устройство на базе TCP в моей сети. У меня та же проблема в симуляторе Blackberry с запущенным симулятором MDS и с использованием физического телефона, разговаривающего с сервером MDS моей компании. Обратите внимание, что эта проблема не возникает при использовании Wi-Fi напрямую, а не через MDS.

Проблема в том, что функция available () в InputStream возвращает ноль, если я сначала не вызову read (). Если я сначала вызываю read (зная, что некоторые данные доступны .. спасибо wireshark), данные возвращаются, и последующий вызов available () указывает, какие данные остались, которые я не прочитал. Проблема в том, что я не всегда буду гарантировать, что данные будут там, и поэтому я могу заблокировать. Кто-нибудь знает об этом, и это проблема или что-то по замыслу?

Кто-нибудь знает способ проверить, будет ли метод read () блокироваться перед вызовом их помимо доступных?

Вот в основном то, что я делаю: 

SocketConnection s = (SocketConnection)Connector.open("socket://1.2.3.4:port;deviceside=false", Connector.READ_WRITE);

OutputStream o = ((StreamConnection)s).openOutputStream();
InputStream i = ((StreamConnection)s).openInputStream();

o.write("hello");
Thread.sleep(sometime);
if (i.available() > 0) {
   byte[] data = new data[10];
   int bytesRead = i.read(data);
   System.out.println("Read [" + new String(data) + "] (bytes = " + bytesRead + ")");
}

Я должен закомментировать условие if, чтобы это сработало.

Ответы [ 2 ]

3 голосов
/ 24 августа 2009

Общий контракт метода InputStream.available () заключается в том, что он «возвращает количество байтов, которые могут быть прочитаны (или пропущены) из этого входного потока без блокировки следующим вызывающим объектом метода для этого входного потока. " Следовательно, в большинстве реализаций нет гарантии, что он вернет длину содержимого потока, который читается. Следовательно, лучше прочитать это следующим образом 

byte[] readFromStream(InputStream is) throws IOException
{
    byte[] data = new byte[4096];
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    DataOutputStream dos = new DataOutputStream(baos);

    int count = is.read(data, 0, data.length);
    while (count != -1)
    {
        dos.write(data, 0, count);
        count = is.read(data, 0, data.length);
    }

    data = baos.toByteArray();

    return data;
}

Вы вызываете метод readFromStream () и получаете возвращенный байт [].

0 голосов
/ 11 сентября 2009

Как я указал в комментарии выше, мне нужен был способ определить, не существует ли устройства, к которому я подключаюсь, и я делаю это, проверяя, возвращает ли наш 'ping' какие-либо данные. Если устройства там нет, оно заблокируется. Я не могу полагаться на это поведение. Другая проблема, которая возникла при решении этой проблемы, заключается в том, что методы read (...) класса RIM InputStream блокируют, если вы предоставляете буфер больше данных, которые вы хотите вернуть. Но как мне узнать, сколько там данных, если available () возвращает 0? Чтение за байтом - это единственный способ сделать это, но он все равно блокируется, если нет данных.

Чтобы решить эту проблему, я следовал теме первого ответа, но я поместил этот метод в свой собственный поток и записал его в отдельный байтовый буфер. Я создал класс, который расширил InputStream и реализовал available () и read (...). Доступно возвращает количество байтов в байтовом буфере, и только чтение возвращает, сколько находится в буфере или сколько запрашивает вызывающая сторона, в зависимости от того, что меньше.

Эта настройка позволяет мне использовать интерфейс InputStream, но за кулисами это просто непрерывно работающий поток чтения, который работает до тех пор, пока не будет разорвано соединение. В это время чтение, если оно заблокировано, выдаст исключение, указывающее, что соединение закрыто. Такое поведение хорошо, так как с ним легко справиться.

Спасибо всем выше, кто помог с этой проблемой. Ваши мысли помогают двигаться к решению.

...