[J2ME] Połączenie z serwerem.

0

W moim midlecie mam opcję wysyłania wyniku gry na serwer.
Połączenie nawiązuję za pomocą Connector:

//...
client = (SocketConnection) c.open("socket://" 
                    + host + ":" + port);

I tutaj pojawia się problem z portem.
Jeżeli testuję program w Wireless Toolkit to na dowolnym porcie aplikacja
działa dobrze, poprawnie łączy się z serwerem, wysyła dane, zamyka połączenie.

Natomiast na komórce, jak gdzieś przeczytałem, dostępne są tylko niektóre porty
np. ERA blokuje wszystkie poza 80 i 443 z tego co się dowiedziałem.
Jeśli teraz z komórki łącze się z serwerem przez port 80 dostaję coś takiego:

( sieć Era i Plus, ale w Orange i Play pewnie będzie tak samo )

Untrusted MIDlet attempted to connect a restricted port

Co mam zrobić, żeby mój midlet stał się "zaufanym" ?
Proszę o pomoc, za kilka dni muszę oddać ten projekt na zaliczenie.

//17:30
Hmm - czy nie chodzi przypadkiem o podpisywanie midletu?

0

Zgadza sie. Niektorzy producenci telefonow blokuja lub obcinaja dostep do Internetu, jezeli midlet nie jest podpisany. W zaleznosci od producenta/modelu w opcjach telefonu moze sie dac zmniejszyc nalozone ograniczenia. Jesli nie, aplikacja bedzie musiala byc podpisana.
Pozdr.

0

Dzięki.
Mógłbyś coś o tym więcej napisać?

Używam NetBeans, daję sign, wybieram trusted, aplikacja zostaje podpisana.
Teraz jeśli próbuję ją odpalić na komórce dostaję komunikat o braku certyfikatu na telefonie/ karcie SIM.

W jaki sposób wgrać ten certyfikat na telefon ?

0

Wszystkie aplikacje napisane w J2ME pracuja w tzw. piaskownicy (sandbox), w ktorej maja ograniczony dostep do zasobow urzadzenia. Restrykcje te odnosza sie do potencjalnie groznych API (np. WMA) lub wybranych metod konfiguracji CLDC (zwykle metody dostepu do Internetu).

Specyfikacja MIDP J2ME wyroznia dwa zestawy MIDletow:
1. niezaufane (untrusted) - kazda aplikacja, ktora NIE jest zaufana (trusted). Mozliwe jest jej uruchomienie, ale z odpowiednimi ograniczeniami. W MIDP1.0 podstawowym ograniczeniem jest dostep do HttpConnection, a dokladniej do Connector.open("http://");. W MIDP2.0 restrykcje obejmuja tez obsluge polaczenia szyfrowanego HTTPS i SSL oraz low-level networking (sockety TCP/IP, datagramy UDP/IP).
Najczesciej zablokowany jest dostep do portow 80 (HTTP), 443 (HTTPS), 8080 (proxy) dla polaczen TCP. SonyEricsson, dla przykladu, dodatkowo blokuje polaczenia UDP na portach 9000, 9001, 9003.
W tym przypadku uzytkownik musi osobiscie wyrazic zgode na udzielenie danej aplikacji dostepu do zasobow. Dostawca MIDletu moze zglosic zadanie przydzielenia uprawnien, umieszczajac odpowiednie wpisy w deskryptorze aplikacji (.jad) lub w manifescie pliku .jar.

2. zaufane (trusted) - MIDlet, ktory jest podpisany certyfikatem. Pomijajac szczegoly sprawdzania podpisu (musi byc spelnionych kilka warunkow), wspomne tylko, ze autentycznosc certyfikatu sprawdzana jest na podstawie "certyfikatu nadrzednego" (root certificate) umieszczonego w telefonie (np. GEOTrust, VeriSIGN). Niektorzy producenci daja mozliwosc dodawania wlasnych certyfikatow.
Jesli aplikacja MIDP2.0 zostanie uznana jako zaufana, przypisywana jest do tzw. "domeny ochrony" (protection domain), ktora okresla, jakie uprawnienia moga byc nadane automatycznie (Allowed) a jakie uzytkownik ma przydzielic osobiscie (User). Domeny definiowane sa wewnetrznie, przez producentow urzadzen.

Kazdy, zaufany lub niezaufany, MIDlet ma dostep do podstawowego API, ktore obejmuje pakiety:

  • javax.microedition.rms
  • javax.microedition.midlet
  • javax.microedition.lcdui
  • javax.microedition.lcdui.game
  • javax.microedition.media
  • javax.microedition.media.control

Projektant aplikacji J2ME moze recznie zarzadac dostepu do okreslonego API lub jego czesci. Do tego celu sluza parametry: MIDlet-Permissions i MIDlet-Permissions-Opt. Pierwszy wskazuje uprawnienia, ktore sa niezbedne do dzialania aplikacji. Drugi wymienia zestaw uprawnien, ktore sa opcjonalne (ich brak oznacza jedynie ograniczona funkcjonalnosc aplikacji).

Przykladowy plik deskryptora .jad:

MIDlet-1: SocketMidlet, , mobile.test.http.SocketMidlet
MIDlet-Jar-Size: 1024
MIDlet-Jar-URL: SocketMidlet.jar
MIDlet-Name: SocketMidlet
MIDlet-Permissions: javax.microedition.io.Connector.socket
MIDlet-Vendor: Vendor
MIDlet-Version: 1.0
MicroEdition-Configuration: CLDC-1.1
MicroEdition-Profile: MIDP-2.0

W srodowisku NetBeans wystarczy wybrac wlasciwosci danego projektu J2ME, potem Application Descriptor i w zakladce API Permissions dodac odpowiednie uprawnienia.
Pozdr.

0

Dzięki J2ME, bardzo mi pomagasz.
Nadal mam pewne problemy, jeśli ich sam nie rozwiążę to wkrótce się odezwę.
Pozdrawiam.

0

Witam!

Mam chyba podobny problem ale mimo wyjaśnień nie udało mi się go rozwiązać. Pomimo iż następuje połączenie wciąż nie można przesyłać danych.

0

witam ja mam podobny problem z odbiorem danych

sc = (SocketConnection)
Connector.open("socket://XXX.XX.XXX.XXX:3307");
is = sc.openInputStream();
StringBuffer sb = new StringBuffer();
int c = 0;

    while (((c = is.read()) != '\n'))
    {
       sb.append((char) c);
         si.setText(sb.toString());
    }</i>

ten kawałek kodu bez problemowo łączy się w Wireless Toolkit jednak gdy tylko włożę go do telefonu moge sobie czekać na odpowiedź do... wiecie czego. Miał ktoś podobny problem może ktoś pomóc? :(

0

Również mam problem związany z łączeniem z serwerem.
Modyfikuję aplikację w J2ME, korzystając z NetBeans IDE w połączeniu z Wireless Toolkit. Aplikacja ta jest
klientem Jabbera.
Łączy się ona z serwerem przez standardowy port (5222), natomiast przy próbie połączenia przez port SSL (5223) wywala błąd: Certificate was issued by an unrecognized entity. :/
Po przeczytaniu powyższych objaśnień próbowałem podpisywać aplikację i dodawać uprawnienia we właściwościach projektu, jednak nic z tego nie wyszło. :/

0

nom ja już siedzę tydzień i nic nie mogę znaleźć......... please help...

0

A projekt masz w profilu MIDP2.0?

0

tak midp2.0 CLDC1.0 i CLDC1.1 taki sam efekt

1 użytkowników online, w tym zalogowanych: 0, gości: 1