Witam
Czy udałoby się to zrealizować przy pomocy standardowych bibliotek Javy?
packet.getData() zwraca mi długość danych w zadeklarowanym buforze, czyli de facto długość całego zadeklarowanego bufora (dane + ewentualnie wypełnienie bufora zerami). Jak określić rzeczywistą długość nagłówka danych w danym przychodzącym pakiecie? W każdym pakiecie może być przecież inna.
Pozdrawiam
Ale jaki nagłówek ty chcesz odczytać? Tcp? Udp? Arp? A może samego IP?
Skonkretyzuj się.
Z samej javy to możesz mieć najwyżej dostęp do warstwy aplikacji
PS. ale sądze, że skoro używasz pojęcia "pakiet" to chodzi Ci o UDP.
Nie ta warstwa - musisz sobie sam socket zaimplementować i wtedy będziesz mógł sobie czytać co chcesz i gdzie chcesz bajt po bajcie, tak jak to widzą urządzenia w sieci.
Piszę o multicast. Więc to UDP. Nagłówek danych (payload). A metoda getData() to na czym działa jak nie na bajtach?
Ale zrozum, że obsługa komunikacji sieciowej jest wykonywana warstwowo. Słyszałeś o modelu OSI ? Jak nie to googleIT!
W związku z powyższym, nie wszystko co widzisz w wiresharku wyciągniesz w swojej aplikacji. (Przynajmniej nie bez implementacji własnej obsługi niższych warstw)
Metoda getData nie działa na niczym, tylko zwraca jak już. A co zwraca? No właśnie "body" danych wysłanych a nie całą ramkę informacyjną.
Po co Ci długość samego nagłówka? (btw - bez sprawdzenia - nagłówki właśnie cą stałej długości...)
Czy tobie nie jest potrzebny rozmiar przesłanych danych (w jednym pakiecie) ?
Bo jeżeli tak, to taką informacje najlepiej umieścić w samym pakiecie np. przeznaczyć pierwsze 4 bajty na określenie ilości następujących bajtów które trzeba traktować jako dane. (Tworzy się w ten sposób jakby własny nagłówek - to tak jakby dołożyć warstwę w modelu;])
A co do ostatniego Twojego postu - payload to nie nagłówek danych tylko właśnie same dane - to co ja nazwałem "body" wyżej.
PS. a tak, faktycznie był multicast w temacie - tak pięknie napisanym temacie ze się na belce tematu nie mieści.
Odnoszę wrażenie, że dyskusja zmierza w złym kierunku. Dlaczego z góry zakładasz pewne rzeczy i dyskredytujesz ludzi? Najpierw zapytaj potem bij. Komunikacja jeszcze nikomu nie zaszkodziła. Sam dobrze wiesz, że z terminologią bywa różnie. Sama wikipedia (https://pl.wikipedia.org/wiki/User_Datagram_Protocol) twierdzi, że pakiet UDP to nagłówek (header), a w nim są odpowiednie pola (i każdy enkapsulowany protokół to dodatkowy nagłówek). Z kolei we frameworkach spotkałem się już z trochę inną konwencją - każde pole to nagłówek. Owszem stosowanie konwencji wiadomo, że ułatwia życie - ale nikt jej nikomu nie narzuca. Czy zwracanie to również nie jest jakaś forma działania? Nie licytujmy się kolego, bo to bez sensu. Co do długości pola danych, to potrzebuję tylko takie przychodzące pakiety UDP o określonej długości tego pola danych - dajmy na to np. 6 bajtów. Nagłówki może i są stałej długości, ale też są takie które nie są wymagane (opcjonalne) i może i najzwyczajniej w świecie nie być w pakiecie (np. suma konrolna w UDP IPv4).
A co do getData() to metoda to zwraca wcześniej zadeklarowany bufor wypełniony właśnie polem danych z pakietu. Jeśli jednak pole danych będzie krótsze niż zadeklarowany bufor zostanie on dopełniony zerami. Oczywiście mógłbym zadeklarować długość bufora na taką wielkość jaką maja interesujące pola danych w pakietach, ale chciałbym znać jednak długość tego pola wcześniej. Wnioskuje jednak, że tego się nie da bez schodzenia na niższą warstwę modelu OSI.
PS. Mi się mieści (a na głównej liście wątków masz dymek/chmurkę z pełna treścią). Regulamin forum narzuca limit znaków w temacie? Moim zdaniem czepiasz się, albo się nudzisz. Przecież nie masz obowiązku uczestniczenia w dyskusjach na tym forum.
Pienia napisał(a):
A co do getData() to metoda to zwraca wcześniej zadeklarowany bufor wypełniony właśnie polem danych z pakietu. Jeśli jednak pole danych będzie krótsze niż zadeklarowany bufor zostanie on dopełniony zerami. Oczywiście mógłbym zadeklarować długość bufora na taką wielkość jaką maja interesujące pola danych w pakietach, ale chciałbym znać jednak długość tego pola wcześniej. Wnioskuje jednak, że tego się nie da bez schodzenia na niższą warstwę modelu OSI.
PS. Mi się mieści (a na głównej liście wątków masz dymek/chmurkę z pełna treścią). Regulamin forum narzuca limit znaków w temacie? Moim zdaniem czepiasz się, albo się nudzisz. Przecież nie masz obowiązku uczestniczenia w dyskusjach na tym forum.
Tak masz racje, czepiam się :)
Nie nie nudzę się mam full zajęć :)
tak GetData zwraca bufor - referencje na niego
możesz odbierać tylko i wyłącznie kontent, nie odczytasz danych warstwy transportowej i sesji bezpośrednio korzystając z implementacji socketów zawartych w sdk. Poza tym, mam wrażenie, że chcesz na siłę zejść warstwę niżej zawijając to co jest wyżej - socket i tak ładuje dane w bufor np w przypadku strumieni, nigdy nie czytasz "bezpośrednio" z sieci a zawsze z bufora danych (nawet sprzętowego) - takie zachowanie jak w przypadku buforowanych strumieni (programowo oczywiście czyli np BufferedInputStream BufferedOutputStream)
Standardowo paczki UDP mają po 8 kb - nie ma co kombinować, tylko przyjąć taką konwencje. Nie wiem czemu chcesz przesyłać takie małe porcje danych.
Problem który Ty przedstawiasz, powinien się właśnie tyczyć dużych ilości danych na które trzeba przygotować n-kb buffor. Czy na serio byłby problem wykorzystywać do odbioru ciągle jeden bufor? Prawdę mówiąc (nie znam Twojego celu działania - nie wiem czemu tak chcesz coś zrobić nie inaczej) to zrobisz większy narzut na zasoby i czas pracy procesora w ten sposób rozwiązując transmisje, niż korzystając z jednego bufora - ale też nie wiem czy to jest Twoim celem.
EDIT. :
Przeczytałem jeszcze raz - rozumiem, chcesz wyciągać pakiety o określonej długości - swoisty filtr.
Nie nie zrobisz tego w sposób przedstawiany przez Ciebie - nie odczytasz bezpośrednio długości pakietu.
Musisz go zaciągnąć, sprawdzić co Ci potrzebne i dalej działać - albo tak jaj już trzeci raz napisze, obsłużyć niższą warstwę i doimplementować metdoę filtrującą do samej implementacji socketa
Dzięki za odpowiedź. Filtrować faktycznie stricto nie mogę. Ale mogę określić bufor na 6 bajtów i sprawdzać co w nim jest w/g zadanych reguł. Jednak aplikacja, która wysyła te interesujące mnie pakiety puszcza je w seriach po 5 (duble, z wiadomych przyczyn w UDP mulitcast - jakiś pakiet raczej na pewno osiągnie cel). Problem jest z tymi dublami. Niekoniecznie muszą przyjść jeden po drugim. Może (nie musi) też przyjść za chwilę taka sama druga seria (ale raczej w pewnym odstępie czasowym 1/4 - 1/2 sekundy). Z każdej serii muszę wydłubać jeden pakiet - reszta jest mi zbędna. Z poziomu standardowych instrukcji Javy nie zbadam raczej w jakim odstępie czasowym przyszły pakiety. Pobranie 5 pakietów i odczekanie tego kawałka czasu to też chyba zły pomysł - nie ma gwarancji, że pakiety UDP w ogóle przyjdą i w danej kolejności, nie przemieszane z innymi pakietami z tego multicastu. Testowałem wrapper jNetPcap, ale tam w nieskończonej pętli loop miałem problemy z przepełnieniem pamięci.