Спасибо, многое прояснилось, но тем не менее... если 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)

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