Nowe posty

xx Dystrybucja pod HP Omen (6)
Wczoraj o 23:30:08
xx [Poradnik] Wyszukiwanie Sterowników (2)
Wczoraj o 21:08:23
lamp Problem z Linux Lite po instalacji (0)
Wczoraj o 19:50:30
xx Ile pingwinów? (1)
Wczoraj o 08:59:24
xx konfiguracja pale moon (0)
2024-03-24, 21:53:42
xx Plasma 6 w Neonie ssie trochę mniej ... (10)
2024-03-23, 02:38:11
xx problem z instalacja sterowników do karty sieciowej (3)
2024-03-18, 18:10:16
xx Plik abc.001 (1)
2024-03-17, 17:48:27
xx Zlecę dopracowanie programu w MatLab (0)
2024-03-13, 15:28:40
xx Linux Mint 21.3 XFCE brak dźwieku po paru minutach (karta muzyczna zintegrowana) (5)
2024-03-12, 23:07:01

Autor Wątek: Dawno nic nie wrzucałem. Oto program do przesyłania pojedyńczego pliku.  (Przeczytany 5043 razy)

Filystyn

  • Gość
Programu nie skończyłem bo jak już mi zadziałał to potem były pomysły na inne rzeczy i lenistwo zwyciężyło. (brak możliwości wznowienia wysyłąnego pliku brak checksumy, brak  pewnych pierdol ).

Nie zmienia to faktu, że wysłałem tym 6gigowy plik od mojego kolegi i wszystko zadziałało.
(sprawdziłem checksume).

Moja obserwacja.
Można spokojnie używać do tego TCP. Nie sądzę aby udp cokolwiek tu przyspieszyło.
Mając tylko jedno IP. Nie byłem w stanie wyciągnąć więcej niż 1 MB/s. Normalnie wiem że moje absolutne max waha się coś koło 8-9. Wniosek: Aby wyciągnac max trzeba by wysyłać albo przez bramki proxy albo któraś ze stron musi dysponować większą liczbą IP.

Program prawdopodobnie wymaga flagi -std=c11., do skompilowania.
Napisałem tylko po ipV4 i tylko pod linuxa. Ze względu na użucie pewnych rzeczy z glibc nie zadziała to na bsd/solaris.

kod: https://paste.fedoraproject.org/537409/

Pozdrawiam.

EDIT:  fedora widze usuwa no to wklejka będzie wisiała na ubuntu https://paste.ubuntu.com/24101881/
« Ostatnia zmiana: 2017-03-03, 14:11:16 wysłana przez Filys »

Offline Paweł Kraszewski

  • Administrator
  • Guru
  • *****
  • Wiadomości: 3049
  • Lenistwo jest matką potrzeby = babcią wynalazku
    • Zobacz profil
Mother of Lord...

* Po coś są funkcje sendfile/copy_file_range/splice.
* Po coś jest zrobiony podsystem mmap.
* Po coś są zaprojektowane mechanizmy ECN/autocorking/sack.
* Po coś powstały biblioteki typu libev/libevent.
* Po co open_readerr_passed() jak jest strerror(3)?
* Po co discsize_left_in_path() sprawdza roota, jak pierwszą rzeczą, którą robi main() jest wywalenie się przy roocie?
* Jak robisz TCP_NODELAY, to powinno być writev() (a nie pierdyliard write() po kilka bajtów) ALBO używać TCP_CORK.
* Jest straszna redundancja kodu - jest wiele funkcji mających praktycznie te same, duże fragmenty.

Strasznie duża napinka, żeby uzyskać odpowiednik tar | nc .... nc | tar, scp, rsync albo któregoś z tysiąca innych gotowych programów do transferu. Innowacją by było np. użycie UDP z FEC, drzewa Merklego do wykrycia już przesłanych kawałków, szyfrowanie i/lub konpresja ruchu albo coś w ten deseń...

Dodatkowo, dużo providerów sieci daje 8-10Mb/s uploadu niezależnie od downloadu, co może dać zaobserwowany 1MB/s.
Paweł Kraszewski
~Arch/Void/Gentoo/FreeBSD/OpenBSD/Specjalizowane customy

Filystyn

  • Gość
Mother of Lord...

* Po coś są funkcje sendfile/copy_file_range/splice.
* Po coś jest zrobiony podsystem mmap.
* Po coś są zaprojektowane mechanizmy ECN/autocorking/sack.
* Po coś powstały biblioteki typu libev/libevent.
* Po co open_readerr_passed() jak jest strerror(3)?
* Po co discsize_left_in_path() sprawdza roota, jak pierwszą rzeczą, którą robi main() jest wywalenie się przy roocie?
* Jak robisz TCP_NODELAY, to powinno być writev() (a nie pierdyliard write() po kilka bajtów) ALBO używać TCP_CORK.
* Jest straszna redundancja kodu - jest wiele funkcji mających praktycznie te same, duże fragmenty.

Strasznie duża napinka, żeby uzyskać odpowiednik tar | nc .... nc | tar, scp, rsync albo któregoś z tysiąca innych gotowych programów do transferu. Innowacją by było np. użycie UDP z FEC, drzewa Merklego do wykrycia już przesłanych kawałków, szyfrowanie i/lub konpresja ruchu albo coś w ten deseń...

Dodatkowo, dużo providerów sieci daje 8-10Mb/s uploadu niezależnie od downloadu, co może dać zaobserwowany 1MB/s.

"Po coś są funkcje sendfile/copy_file_range/splice."
Nie znałem tych funkcji,  Nauczka na przyszłość.

"* Po coś jest zrobiony podsystem mmap."
No to prawda mogłem tego użyć, nawet o tym myślałem ale stwierdziłem, że aaa dobra. Mmap nie jest takie przyjemne do stosowania tbh.

"* Po coś są zaprojektowane mechanizmy ECN/autocorking/sack."
To musiałem doczytać.
Sack pewnie by dał radę. Ale idea była taka, że jak check suma się nie zgadza za którymś razem (wiem nie zrobiłem tego). To zepsuty kawałek by był retransmitowany.
Poza tym w internecie pisało, że sack nie nadaje się do dużych plików. Wreszcie nie przypominam sobie any sack dało się ustawić w opcjach socketów.

TCP_Autocorking to jakaś nowość chyba bo tego nie kojarzę.  (skąpe opisy w necie).

O ECN też pierwsze słyszę. Wygląda że dość stare ale nie kojarze jak to włączyć.

Na oko ECN i SACK można przez info zakomunikować ale czy to się wiąze z włączeniem to nie wiem.

"* Po coś powstały biblioteki typu libev/libevent."
Chciałem napisać sam. Generalnie ideałem byłoby trzymac się samego POSIXA ale cóż ;-)

"* Po co open_readerr_passed() jak jest strerror(3)?"
Kulawa funkcja aby uniknąć wywalenia całego programu a tylko zawiadomienai, że pliku nie można otworzyć z jakiegoś powodu.

"* Po co discsize_left_in_path() sprawdza roota, jak pierwszą rzeczą, którą robi main() jest wywalenie się przy roocie?"
Funkcja przeniesiona z mojej mini biblioteki. Jak i Wiele innych funkcji. nie ma linkowania bo nieskończona bib.

* Jak robisz TCP_NODELAY, to powinno być writev() (a nie pierdyliard write() po kilka bajtów) ALBO używać TCP_CORK.
A wysłanie z TCP_CORK wszystkiego naraz co mi daje?
Z writev to pewnie bym musiał mieć wiele buforów. Ale faktycznie pomysł dobry.

"* Jest straszna redundancja kodu - jest wiele funkcji mających praktycznie te same, duże fragmenty."
Część rzeczy była kopiowana z innego kodu jak wspomniałem I jest uzasadnione aby nie mnożyć functioncall ;-).

"
Strasznie duża napinka, żeby uzyskać odpowiednik tar | nc .... nc | tar, scp, rsync albo któregoś z tysiąca innych gotowych programów do transferu. Innowacją by było np. użycie UDP z FEC, drzewa Merklego do wykrycia już przesłanych kawałków, szyfrowanie i/lub konpresja ruchu albo coś w ten deseń... "

No ale jak samemu się nie zrobi to pewnych rzecyz się nie nauczy wg mnie / nie sprawdzi.
Rsync używa UDP o ile kojarze ale tam po prostu jest checksuma co 1kB.

"Dodatkowo, dużo providerów sieci daje 8-10Mb/s uploadu niezależnie od downloadu, co może dać zaobserwowany 1MB/s."
Wydawąło mi się zawsze że Ktorrent przesyła jeszcze szybciej jakimś cudem.
Ja wyciągnąłem te 6,5 giga w 45 min więc jeszcze mnie to zadowoliło. Ale liczyłem na szybciej. W sieci lokalnej śmigało ekstra;-)

Dziękuję za odpowiedź. Zainteresuję się tym czego nie wiedziałem.
« Ostatnia zmiana: 2017-01-28, 13:33:18 wysłana przez Filys »

Offline Paweł Kraszewski

  • Administrator
  • Guru
  • *****
  • Wiadomości: 3049
  • Lenistwo jest matką potrzeby = babcią wynalazku
    • Zobacz profil
Przeczytaj sobie C10k. Co prawda to bardziej o skalowaniu w poziomie niż w pionie, ale i tak możesz wykorzystać wiele technik i porad.
Paweł Kraszewski
~Arch/Void/Gentoo/FreeBSD/OpenBSD/Specjalizowane customy