Скажите пожалуйста как зделать такое:
- создать коннекшин г веб-серверу
- несколько раз его использовать, тоесть несколько раз передать-получить даные?
Спасибо

Ну я так делал:



Код может и не сильно хороший, но времени не много было, чтоб лучше написать.
А потом каждый раз нужно будет создавать новый коннекшн, ну или запихать эт все в отдельный класс(например ServerConnection) или метод и передавать тока URL, плюс сделать нормальную генерацию всех исключений, и отлавливать их выше.

Это сообщение отредактировал(а) W0LF - 8.3.2006, 16:25

W0LF,
А как несколько раз использовать метод POST?
И ещё, у меня следующая функция работает на эмуляторе WTK22, а на телефоне NOKIA 6230i - нет...

практика показывает, что даже если делать connection.close(), то GPRS соединение(или как данное соединение грамотно обозвать) живет некоторое время - т.е. AMS не закрывает его, таким образом 2 подряд поста проходят достаточно быстро

Да, так оно и есть!

И как решить проблемму?
Мне нужно сделать 2 POSTа:
В первом "посте" передаётся пароль и логин, а во втором - новый тарифный план.
А может где-нить есть исходники аналогичной реально работающей программы?

Это сообщение отредактировал(а) Cyr - 21.3.2006, 08:56

Cyr, да просто засылай подряд, в чем проблема то ?

redrick,
в том, что не работает.
На экран ничего не выводит, хотя на эмуляторе всё выводит.

ну тут сложно попасть пальцем в небо... показывай код
из известных мне граблей - убери вызов flush()

Cyr, просто вызывай свой метод два раза и не забудь в заголовке прописать Content-Length и его длинна должна соответствовать длинне POST запроса.

Похожая проблема.. Есть некий сервер www.server.com. Мобильный клиент постоянно обращается к нему с запросами www.server.com/request.php?param1=value&param2=blablabla через HttpConnection через определенные промежутки времени. Мне бы хотелось не разрывать соедининие с серваком каждый раз, т.к. напрягает и сервер и телефон. Слышал что это можно сделать с помощью request property "Keep-Alive" но конкретного примера не нашел, а методом тыка пока никак не получается. Если кто может привести пример рабочего кода, был бы очень признателен. 

nagliyvred, соединение GPRS не разрывается пока ты не выйдешь из мидлета.
 

Да дело не в этом. Допустим у меня есть код:

т.е. на каждой итерации соединение создается (Connector.open()), считывается и разрывается. я хочу сделать нечто вроде:

Т.е не разрывать/создавать новое соединение без необходимости.  

Создавать соединение, а потом его закрывать - это и есть правильный принцип работы с передачей/приемом данных.

Делаешь метод который выполняет соединение, а потом закрывает соединение и передавай ему в качестве параметров то что должно быть в запросе.



Далее вызывай метод сколько надо раз, например по таймеру.
И лучше не используй flush он на некоторых серверах глючит, один из признаков это "зависание" запроса.   

Это сообщение отредактировал(а) javastic - 11.5.2006, 10:08

такое замечание:

nagliyvred, когда соединение "разрывается" с точки зрения твоего мидлета, это всего лишь значит, что разрывается http соединение, однако TCP коннект остается (об этом заботится AMS). В http 1.1 все соединения именно такие "остающиеся" по умолчанию, т.е. TCP соединение между сервером и клиентом T(а это в нашем случае AMS) не разрывается. А вот http соединение - это по определение 1 запрос и 1 ответ, после этого оно закрывается всегда - такой протокол.

Надеюсь, прояснил что-то. 

Спасибо, многое прояснилось, но тем не менее... если http соединение "одноразовое", то что за request property  "keep-alive"? И вобщем-то это не решает мою проблему - а она в том что при постоянном созданиии соединения во первых быстро садится батарекйка, во вторых - серваку к которому я коннекчусь приходится каждый раз создавать новый сокет... 

Здравствуйте. Я тоже не могу решить похожую проблему. Нужно передать на страницу логин и пароль методом POST, после этого на том, что откроется выбрать определенный параметр тоже методом POST (например, techplan=3).
Делаю первый запрос:

После этого успешно попадаю на страницу (логин проходит).
А вот дальше не пойму - что сразу же делать второй запрос?
Если опять использовать OS.write(xxxxx) то логин не проходит, так как по всей видимости строка со второго write просто прибавляется к первой. Как сделать второй запрос именно после авторизации?

Я столкнулся с тем, что такой код
  

на некоторых телефонах не всегда работает корректно. Конкретно вот эта его часть:
while ((ch = is.read()) != -1)
Потому что если получаемые данные двоичные (в моем случае из-за шифрования), то в середине иногда встречался -1. Соответственно, часть данных терялась. Поэтому пришлось куда-то сохранять три последних байта, и если они все -1, то тогда считать, что это конец пакета. Как раз на Nokia была такая трабла.

В случае HTTP я сторонник все же варианта: подключился, отправил запрос, получил ответ, отключился. Web-сервер ориентирован на такую работу.  Этот механизм позволит ему обработать большое кол-во запросов клиентов. Иначе пара тысяч незакрытых соединений завесит его по-любому. Аналогия с сервером Oracle при работе в режиме выделенного или shared сервера. В случае выделенного на каждое подключение содается отдельный поток и с ним идет работа. Хорошо в случае десятков клиентов, в случае тысяч - беда, лучше юзать shared.
Тут создается конечный пул потоков и при новом подключении выбирается свободный, быстро проходит запрос и он освобождается для нового подключения. Естественно, запрос должен быть "небольшой", т.е. быстро обрабатываемым. В противном случае все зависнет еще быстрее, т.к.  пул конечный, забив все потоки остальные встанут  в очередь.

По поводу второго подключения после авторизации. Вариантов несколько. Типичный - это сохранение состояния на стороне сервера.  
Напимер в ASP для этого можно юзать объект Session. При подключении клиента и его авторизации в Session вписывается, например,  код клиента. В следующий раз при подключении смотрим если Session не пустой, то авторизация уже была проведена ок. 
Но для этого клиент должен поддерживать Cookies. 

Можно генерировать самостоятельно при авторизации какую-нибудь сессию (например GUID+IP клиента или типа того). И после авторизации отправлять ее клиенту. Соответсвенно в каждом запросе последующем ее надо передавать, дабы сервер по списку текущих сессий мог сразу понять, что авторизация уже проведена.

Ну и можно в каждом запросе передавать логин/пароль + данные, которые нужны в конкретном случае. Т.е. по любому сначала проводить идентификацию, аутентификацию и авторизацию, а потом уже обрабатывать собственно запрос.

Если где наврал - не со зла 

Это сообщение отредактировал(а) VOS - 26.9.2007, 10:02

Двоичные данные можно например кодировать в encode64

Согласен,  но трафик при этом растет.  В моем случае убедить, что это необходимые издержки производства не получилось. Удалось лишь убедить не сжимать пакет предварительно (и то удивляюсь).

Но согласись, что чем то всё равно придётся жертвовать. Идеального решения не получиться.

Добавлено через 7 минут и 24 секунды
Попробуй читать в буфер определённого размера, так должно 100% получиться. (без проверки на -1)

Проблему-то я решил давно, просто заострил внимание на такой возможной ситуации. Может кто еще на те же грабли наступит. Но все равно спасибо за участие.