client socket - bądz inny sposób komunikacji z serwerem

witam  
zamierzam napisać dość ciekawy aplikacje, a może i raczej system informatyczny.. no i problem polega na tym, że dane z PPC muszę przesłać do serwera, no jak na razie to mam jakby dwa warianty tej komunikacji :
 - socket (napisać prosty protokół serwer/client)
 - wysłać dane mailem

no chyba, że ktoś jeszcze ma jakiś pomysł?  
już odrazu mówię, że sms odpada  

no i kolejne pytanie... ktoś pisał coś na socketach pod PPC?
jeśli tak to w czym?  

ja polecam .net compact framework posiada bardzo rozbudowany system sieciowy ale niektórzy go odradzają za dużą zasobożerność. fakt faktem ale jak dla mnie nie jest ona wcale taka duża. ja napisałem aplikację do sterowania PC po WLAN'ie w NET CF i Socket'ach. nie ma to jak oglądać film i używać poketa do sterowania odtwarzaczem  

Poza tym - oczywiście C++ ale ja ci w tym nie pomogę.

Co do samego sposobu komunikacji - ja preferowałbym socket głównie przez to że transmisja odbywa się w czasie rzeczywistym. To ważne w systemie informatycznym. Pamiętaj że Pocket w większości przypadków ma prywatny adres IP, w związku z czym postawienie na nim serwera nie jest rozsądnym rozwiązaniem (z internetu nie połączymy się z nim chyba że przekierujemy port).
Można ominąć to ograniczenie stosując protokół Gadu-Gadu za pomocą kontrolki (w NET CF) lub samodzielnie napisanej klasy (C++).

VC++ 4.0
Najlepiej oczywiście przez TCP/IP (Csocket)

W czasie tworzenia projektu (w AppWizard) dołączasz "Windows Sockets".

Jako klient podłączasz się do serwera, wysyłasz, odłączasz się:

CSocket soc;
soc.Create(); // Inicjowanie gniazda; użycie dowolnego portu
soc.Connect(TEXT("192.168.0.2"),100); // Połączenie z serwerem przez port 100
soc.Send("ABCD\n",5,0);// 4 znaki + koniec linii
soc.Close();

Jak masz kiepską karte WiFi to łączenie trwa chwilę i w aplikacji można zrobić żeby podłączała się do serwera podczas startu i odłączała podczas zamykania. W trakcie pracy wysyłasz tylko komunikaty soc.Send.

witam  
zamierzam napisać dość ciekawy aplikacje, a może i raczej system informatyczny.. no i problem polega na tym, że dane z PPC muszę przesłać do serwera, no jak na razie to mam jakby dwa warianty tej komunikacji :
 - socket (napisać prosty protokół serwer/client)
 - wysłać dane mailem

no chyba, że ktoś jeszcze ma jakiś pomysł?  
już odrazu mówię, że sms odpada  

Zdziwiony jestem, że nie przyszedł ci do głowy: HTTP. Najpopularniejszy nośnik protokołu wyższego poziomu, przechodzi przez firewalle, serwer może byc wirtualny, proxy.
Każda aplikacja naprawdę sieciowa ma to przynajmniej jako zapasowy protokół.
Powiedzialbym też, ze prawdziwy programista sieciowy ...

Krzywo patrzę na porady kolegów (nie obraźcie) się "umiem używac łopatkę, więc uzyję łopatki". Spotkałem się z jakąś techniką więc ta jest najlepsza.
Mam swojego pierwszego fiacika126 więc fiaciki są najlepszymi samochodami świata.

Blady1
jak obsłużyć socket to nie musisz tłumaczyć :-) wiem jak to działa i z czym to się je

Zdziwiony jestem, że nie przyszedł ci do głowy: HTTP. Najpopularniejszy nośnik protokołu wyższego poziomu, przechodzi przez firewalle, serwer może byc wirtualny, proxy.
Każda aplikacja naprawdę sieciowa ma to przynajmniej jako zapasowy protokół.
Powiedzialbym też, ze prawdziwy programista sieciowy ...

nie musi to być HTTP żeby przechodził przez firewalle...
z drugiej strony wpadłem na pomysł, żeby bezpośrednio łączyć się z baza danych z PPC, zapewne po drodze parę rzeczy się zmieni... narazie to tworze  szczegółowy projekt :-)

oczywiście czekam na dalsze propozycje i sugestie :-)

nie musi to być HTTP żeby przechodził przez firewalle...

Rozumiem podasz przykład?

z drugiej strony wpadłem na pomysł, żeby bezpośrednio łączyć się z baza danych z PPC, zapewne po drodze parę rzeczy się zmieni... narazie to tworze  szczegółowy projekt :-)

Łączenie bezpośrednio na bazę oczywiście jest od czasu do czasu i na pewno spotkasz kolegę-naganiacza który będzie ci to polecał, ale to się postrzega jako amatorszczyznę i nie spotkałem ani jednego profesjonalnego rozwązania tego typu.

Nie wchodzę w szczególy dlaczego (nie będę pisał książek za darmo)

Ile (sztuk) będziesz łączył? Klientów i serwerów?

VC++ 4.0
Najlepiej oczywiście przez TCP/IP (Csocket)

W czasie tworzenia projektu (w AppWizard) dołączasz "Windows Sockets".

Jako klient podłączasz się do serwera, wysyłasz, odłączasz się:

CSocket soc;
soc.Create(); // Inicjowanie gniazda; użycie dowolnego portu
soc.Connect(TEXT("192.168.0.2"),100); // Połączenie z serwerem przez port 100
soc.Send("ABCD\n",5,0);// 4 znaki + koniec linii
soc.Close();

Jak masz kiepską karte WiFi to łączenie trwa chwilę i w aplikacji można zrobić żeby podłączała się do serwera podczas startu i odłączała podczas zamykania. W trakcie pracy wysyłasz tylko komunikaty soc.Send.

Podaj przykład odbioru, będzie ambitniejszy.

Podaj przykład odbioru, będzie ambitniejszy.

socket.odbieraj;  

Rozumiem podasz przykład?

mi to bardziej chodzi o to, że nie będę miał problemu czy to przejdzie przez firewall bo to nie problem, żeby dany port był otwarty... m.in. o to mi chodziło w wypowiedzi wyżej

Ile (sztuk) będziesz łączył? Klientów i serwerów?

nie jestem wstanie Ci na dzień dzisiejszy powiedzieć ile to będzie klientów, na dzień dzisiejszy to jest jeden serwer i załóżmy 50-100 klientów, którzy będą przesyłali dane do bazy co 10-20 minut, bądź jeszcze rzadziej, to są czyste założenia, narazie myślę jeszcze nad ta komunikacja

z drugiej strony jak widzisz (w dużym skrócie) komunikacje z wykorzystaniem HTTP?

socket.odbieraj;  

daruj sobie

z drugiej strony jak widzisz (w dużym skrócie) komunikacje z wykorzystaniem HTTP?

Rozwiazanie bardzo proste. Na serwerze stawiasz jakis serwer aplikacyjny (w zaleznosci od skomplikowania tej warstwy moze to byc apache + php, tomcat, jboss [dwa ostatnie to Java]). Twoja aplikacja wysyla requesty do serwera przekazujac argumenty GET-em lub POST-em. Dzieki takiemu rozwiazaniu nie musisz sie martwic o warstwe sieciowa - tzn. nie musisz sam pisac serwera, ktory by nasluchiwal na jakims porcie, odbieral nadchodzace polaczenia i tworzyl watki do ich obslugi. Wszystko za Ciebie zalatwi serwer aplikacyjny.

Cytat: "alkatraz"

z drugiej strony jak widzisz (w dużym skrócie) komunikacje z wykorzystaniem HTTP?

Rozwiazanie bardzo proste. Na serwerze stawiasz jakis serwer aplikacyjny (w zaleznosci od skomplikowania tej warstwy moze to byc apache + php, tomcat, jboss [dwa ostatnie to Java]). Twoja aplikacja wysyla requesty do serwera przekazujac argumenty GET-em lub POST-em.

lub w nagłowkach itd. Serwer funkcjonalności twoje apliakcji piszesz w czym chcesz i umiesz (np. u mojego ISP w module czyli szybkie jest wyłącznie PHP)

Dzieki takiemu rozwiazaniu nie musisz sie martwic o warstwe sieciowa - tzn. nie musisz sam pisac serwera, ktory by nasluchiwal na jakims porcie, odbieral nadchodzace polaczenia i tworzyl watki do ich obslugi. Wszystko za Ciebie zalatwi serwer aplikacyjny.

i używasz bardzo popularnej technologii, każdy kumpel ci pomoże.

Tylko zwrot wyniku 'od serwera' nie jest ślicznym kolorowym wizualnym HTML-em, ale co ci sie wyda: status udało się/nie w nagłowkach 200,30x,50x,40x, albo więcej wyników w TXT lub XML (dla elegancji pamiętać o mine/type)

Algorytmy serwerowe debuggujesz na pomoca przeglądarki internetowej.
Chcesz szyfrować kanał? 10 minut roboty.
Dasz kompresję (gzip) masz oszczędnośc na GPRS.

A porównaj: znajdź błąd na aplikacji Socketowej.

HTTP z tytułu że i tak jest 'przerywany' dobrze znosi chwilowe zaniki połączenia. Na łączu bezpośrednim na bazę  nie jest tak dobrze, zrób 100 połączeń (plus 1/3 wiszących jakiś czas bo zerwanych) admin ci urwie [----] coś. Transakcje na bazie też wiszą, trzymają cząstkowe dane, będą kiedyś wycofane itd itd.

Poczytaj o API Googla (GData API). Wszytko na http (dośc ambitne!!!)


Z wad http co do socketa, głowna, że nie masz fajnego kanału jak serwer chce ci coś powiedzieć a ty nie słuchasz. Musisz coś okresowo robić (odpytywać).

Rozwiazanie bardzo proste. Na serwerze stawiasz jakis serwer aplikacyjny (w zaleznosci od skomplikowania tej warstwy moze to byc apache + php, tomcat, jboss [dwa ostatnie to Java]). Twoja aplikacja wysyla requesty do serwera przekazujac argumenty GET-em lub POST-em. Dzieki takiemu rozwiazaniu nie musisz sie martwic o warstwe sieciowa - tzn. nie musisz sam pisac serwera, ktory by nasluchiwal na jakims porcie, odbieral nadchodzace polaczenia i tworzyl watki do ich obslugi. Wszystko za Ciebie zalatwi serwer aplikacyjny.

apache z php będę miał, bazę trzeba jakoś obsłużyć no to rozwiązanie mi się podoba

Algorytmy serwerowe debuggujesz na pomoca przeglądarki internetowej.
Chcesz szyfrować kanał? 10 minut roboty.
Dasz kompresję (gzip) masz oszczędnośc na GPRS.

A porównaj: znajdź błąd na aplikacji Socketowej.

HTTP z tytułu że i tak jest 'przerywany' dobrze znosi chwilowe zaniki połączenia. Na łączu bezpośrednim na bazę nie jest tak dobrze, zrób 100 połączeń (plus 1/3 wiszących jakiś czas bo zerwanych) admin ci urwie [----] coś. Transakcje na bazie też wiszą, trzymają cząstkowe dane, będą kiedyś wycofane itd itd.

No to szyfrowanie kanałów nie jest głupie, jak to wygląda? Nigdy się z tym nie bawiłem, prawdę mówiąc... Co do kompresji danych to naprawdę jest to zbyteczne,do serwera będą przesyłane stringi (2 bądź 3) o max. długości 10 znaków

Cytat: "gotrek"

Rozwiazanie bardzo proste. Na serwerze stawiasz jakis serwer aplikacyjny (w zaleznosci od skomplikowania tej warstwy moze to byc apache + php, tomcat, jboss [dwa ostatnie to Java]). Twoja aplikacja wysyla requesty do serwera przekazujac argumenty GET-em lub POST-em. Dzieki takiemu rozwiazaniu nie musisz sie martwic o warstwe sieciowa - tzn. nie musisz sam pisac serwera, ktory by nasluchiwal na jakims porcie, odbieral nadchodzace polaczenia i tworzyl watki do ich obslugi. Wszystko za Ciebie zalatwi serwer aplikacyjny.

apache z php będę miał, bazę trzeba jakoś obsłużyć no to rozwiązanie mi się podoba

Prawda? ma to plusy. Serwer aplikacyjny za 200zł/rok.

Cytat: "jacek.czerwinski"

Algorytmy serwerowe debuggujesz na pomoca przeglądarki internetowej.
Chcesz szyfrować kanał? 10 minut roboty.
Dasz kompresję (gzip) masz oszczędnośc na GPRS.

A porównaj: znajdź błąd na aplikacji Socketowej.

HTTP z tytułu że i tak jest 'przerywany' dobrze znosi chwilowe zaniki połączenia. Na łączu bezpośrednim na bazę nie jest tak dobrze, zrób 100 połączeń (plus 1/3 wiszących jakiś czas bo zerwanych) admin ci urwie [----] coś. Transakcje na bazie też wiszą, trzymają cząstkowe dane, będą kiedyś wycofane itd itd.

No to szyfrowanie kanałów nie jest głupie, jak to wygląda? Nigdy się z tym nie bawiłem, prawdę mówiąc... Co do kompresji danych to naprawdę jest to zbyteczne,do serwera będą przesyłane stringi (2 bądź 3) o max. długości 10 znaków

1. https. Osobiście (na dużych Win) używam curl, na małych też będę (nie leży mi API MS do http). Przełączenie opcji/stringa w adresie  (plus zainstalowane DLL-ki)
2. Trochę wiecej niż 10 zn, oprawa protokołu (narzuty to akurat słabość http) jak urośniesz do pierwszej 10-ki www w PL, będziesz musial przejśc na sockety/datagramy. Ale to wtedy wynajmiesz sobie najlepszych sieciowców (nie z forum) Czego życzę

1. https. Osobiście (na dużych Win) używam curl, na małych też będę (nie leży mi API MS do http). Przełączenie opcji/stringa w adresie  (plus zainstalowane DLL-ki)

no będę coś kombinował, jak mówiłem to są jeszcze plany, trzeba to jeszcze ugadać z promotorem... bo owe COŚ jest tematem pracy dyplomowej

2. Trochę wiecej niż 10 zn, oprawa protokołu (narzuty to akurat słabość http) jak urośniesz do pierwszej 10-ki www w PL, będziesz musial przejśc na sockety/datagramy. Ale to wtedy wynajmiesz sobie najlepszych sieciowców (nie z forum) Czego życzę

hehe marzenie, zobaczymy czy się przyjmie za jakiś rok  
w każdym bądź razie jak będzie wersja beta to prawdopodobnie parę osób stąd zgarnę (o ile będą chętni) do testowania

Jacek i dzięki za rady, naświetliłeś mi tą sprawę z innej strony

Jacek i dzięki za rady, naświetliłeś mi tą sprawę z innej strony

Mój (były) wspólnik miał jedną fajną zasadę. (inne też)
"U mnie doradzający ma jedno prawo: zrobić samemu to, co doradza"

Zdziwiony jestem, że nie przyszedł ci do głowy: HTTP. Najpopularniejszy nośnik protokołu wyższego poziomu, przechodzi przez firewalle, serwer może byc wirtualny, proxy.
Każda aplikacja naprawdę sieciowa ma to przynajmniej jako zapasowy protokół.

Może trochę offtop... ale ost. pisałem aplikację w J2ME na komórkę - ponieważ jest tam protokół HTTP (musi być wg. specyfikacji poszczególnych profili i konfiguracji takiego urządzenie) - więc mogłem bez problemu łączyć się z serwerem Tomcat'a a za jego pośrednictwem z bazą MySQL (wszystko freeware). Na Tomcacie (załóżmy jest to coś jak Apach, po prostu serwer aplikacji) napisałem dodatkowo serię stron JSP dostępnych również z kompa w sieci lub z innej maszyny stacjonarnej poprzez internet (zwykła przeglądarka internetowa) - za pomocą których bez problemu można administrować zawartością bazy. Dodatkowy kod JSP (odzielne serwlety) pośredniczyły między Midletem na komórce a bazą danych - przetwarzając żądanie od klienta, formułując zapytanie do bazy, pobierając odpowiedź i wysyłając wcześniej obrobioną porcję danych do klienta.

Wszystko przez HTTP pięknie śmiga... liczba użytkowników dosyć duża - i się wyrabia.... U mnie był problem że na komórkach niestety przy połączeniu nie mogę wykorzystać ani szyfrowania ani innych zabezpieczeń połączenia (ew. samemu można szyfrować dane).

PS.: Pisałem aplikację do obsługi rezerwacji w bibliotece publicznej... i definitywnie polecam HTTP do tego typu rozwiązań.


Pozdr.
(...i sorki za małą moją dygresję... ale alcatraz może chociaż upewnisz się w stosunku do takiego rozwiązania jak wyżej zostało zaproponowane przez przedmówców)

Może trochę offtop... ale ost. pisałem aplikację w J2ME na komórkę - ponieważ jest tam protokół HTTP (musi być wg. specyfikacji poszczególnych profili i konfiguracji takiego urządzenie) - więc mogłem bez problemu łączyć się z serwerem

Jakie masz środki do debuggowania tego co fruwa przez drut? Nie mam wpływu na server bo to google  

Cytat: "arczi"

Może trochę offtop... ale ost. pisałem aplikację w J2ME na komórkę - ponieważ jest tam protokół HTTP (musi być wg. specyfikacji poszczególnych profili i konfiguracji takiego urządzenie) - więc mogłem bez problemu łączyć się z serwerem

Jakie masz środki do debuggowania tego co fruwa przez drut? Nie mam wpływu na server bo to google  

Panie Jacku... ja coś chyba mało domyślny jestem.. jakie google??? Nie załapałem kontekstu....

Jeśli chodzi o połączenie - to tak jak w życiu... jest albo nie ma - i koniec. Nie będę sprawdzał czy gdzieś w sieci jest jakiś problem uniemożliwiający nawiązanie połączenia - bo to już była by delikatna przesada... Osoba zarządzająca serverem już powinna zadbać aby był on osiągalny a aplikacja tak napisana aby przez dostępny protokół prawidłowo mogła połączyć się z serverem.

A debuggowanie - jeśli chodzi o J2ME - są narzędzia pozwaljące w bardzo fajny sposób analizować pracę midletu... - odsyłam np. do "J2ME - Almanach". Osobiście przy tym projekcie (o dziwo) nie używałem debuggera - projekt był na tyle nieskomplikowany że jakoś nie czułem potrzeby.

Pozdrawiam.

Cytat: "jacek.czerwinski"

Cytat: "arczi"

Może trochę offtop... ale ost. pisałem aplikację w J2ME na komórkę - ponieważ jest tam protokół HTTP (musi być wg. specyfikacji poszczególnych profili i konfiguracji takiego urządzenie) - więc mogłem bez problemu łączyć się z serwerem

Jakie masz środki do debuggowania tego co fruwa przez drut? Nie mam wpływu na server bo to google  

Panie Jacku... ja coś chyba mało domyślny jestem.. jakie google??? Nie załapałem kontekstu....

np. Google calendar

Jest opensopursowy J2ME program http://www.gcalsync.com/ do synchronizacji Google Calendarza z komórką, piszą że z niektórymi komórkami powiela wpisy.
Widocznie moja SE 510i do takich należy :-(

Jasne, łaczy sie itd (po wybraniu właściwego połączenia dla apliakcji J2ME, bo na Orangu jest ich aż za dużo). Założę się, że nie dogadują sie na identyfikatorze zdarzenia.

PS. Jak dla J2ME uniknąc stale tych samych pytań  w rodzaju: czy pozwolisz apliakcji wysyłać dane .... Czy jest na to jakiś standard, czy każdy sobie? Aplikacja (JAR) chyba podpisany.

np. Google calendar

Jest opensopursowy J2ME program http://www.gcalsync.com/ do synchronizacji Google Calendarza z komórką, piszą że z niektórymi komórkami powiela wpisy.
Widocznie moja SE 510i do takich należy :-(

Hmmm... nie wiedziałem o takim sofcie. A powiela wpisy - możliwe dlatego że po prostu system źle skonstruowany (midle/server nie ma odp. mechanizmów zabezpieczających?)

Jasne, łaczy sie itd (po wybraniu właściwego połączenia dla apliakcji J2ME, bo na Orangu jest ich aż za dużo). Założę się, że nie dogadują sie na identyfikatorze zdarzenia.

hmmm... tak głęboko nie wgryzałem się w temat - widzę w tym zakresie ma Pan znaaacznie większą wiedze ode mnie... ale zgłębię temat w wolnej chwili :-)

PS. Jak dla J2ME uniknąc stale tych samych pytań  w rodzaju: czy pozwolisz apliakcji wysyłać dane .... Czy jest na to jakiś standard, czy każdy sobie? Aplikacja (JAR) chyba podpisany.

Faktycznie denerwujące... ale nie znalazłem sposobu ominięcia tych komunikatów... zresztą nie jestem pewien czy to z kvm pochodzą takie inf. - raczej sam system operacyjny ma zabezpieczenia przed wysyłaniem danych - a tego to już raczej prosto nie da się ominąć z poziomu Javy (ograniczenia, ograniczenia, ograniczenia....)


Pozdr.

Cytat: "jacek.czerwinski"

np. Google calendar

Jest opensopursowy J2ME program http://www.gcalsync.com/ do synchronizacji Google Calendarza z komórką, piszą że z niektórymi komórkami powiela wpisy.
Widocznie moja SE 510i do takich należy :-(

Cytat: "jacek.czerwinski"

PS. Jak dla J2ME uniknąc stale tych samych pytań  w rodzaju: czy pozwolisz apliakcji wysyłać dane .... Czy jest na to jakiś standard, czy każdy sobie? Aplikacja (JAR) chyba podpisany.

Faktycznie denerwujące... ale nie znalazłem sposobu ominięcia tych komunikatów... zresztą nie jestem pewien czy to z kvm pochodzą takie inf. - raczej sam system operacyjny ma zabezpieczenia przed wysyłaniem danych - a tego to już raczej prosto nie da się ominąć z poziomu Javy (ograniczenia, ograniczenia, ograniczenia....)

A nawet znalazłem w opcjach telefonu. Można pozwolić, choć menu w polskiej wersji jest debilne.
"Nie" to znaczy a) nie pytaj (zabroń na sztywno), b) nie zabraniaj, c) inne?

Ciekawostka, że (pewnie ze względu na podpis) inne menu Uprawnień jest dla w/w aplikacji (podpisanej thatwe), a inne dla J2ME klienta Gmaila (oryginał od googla, o paradoksie jako nie zaufana domena)
W każdym razie ten program mi o nic już nie pyta. Synchronizacja kalendarza (kilka zdarzeń) kosztuje 30-50kB GPRS-u.

No Panie Jacku - znalazł Pan... ja się do tego nie dogrzebałem niestety... Dobrze wiedzieć o takich możliwościach (muszę prześledzić u mnie instrukcję tel. czy coś takiego mam na mojej stareńkiej Motoroli T720)

Pozdr.

Jak czytam te posty to się zastanawiam, czy zrozumieliście pytanie? - Pytanie też było zadane nieprecyzyjnie, analogicznie można się zapytać: "Czym mam pojechać? a) czymś, co ma dwa kółka b) rowerem".

Wszyscy piszą o http, a niby jak dane są przesyłane? To też przecież połączenia TCP (czyli sockety). A więc dyskusję o firewallach można pominąć, bo jeśli nie można połączyć się za pomocą socketów, to http tym bardziej nie będzie działało.

Odpowiedź: protokół trasmisji TCP (socket), protokół wymiany danych HTTP, rodzaj danych np. XML