[teknologia] Re: Mengirim message panjang di linux
baskara wrote: On 2/11/06, Ary Setijadi Prihatmanto [EMAIL PROTECTED] wrote: Bisa cerita bagaimana masalah bufferingnya? Menurut manpage of raw: Raw sockets fragment a packet when its total length exceeds the interface MTU (but see BUGS). ngomong2 MTU , kita tahu kalau ethernet mtu 1500 bytes, tapi di sebagian printer server older model?? (yang di embed di printer) itu ada yang mtu-nya cuman 200-300an bytes lho. Carlos --~--~-~--~~~---~--~~ Anda menerima pesan ini karena Anda tergabung pada grup Grup Google teknologia grup. To post to this group, send email to teknologia@googlegroups.com Untuk keluar dari grup ini, kirim email ke [EMAIL PROTECTED] Untuk pilihan lainnya, lihat grup ini pada http://groups.google.com/group/teknologia -~--~~~~--~~--~--~---
[teknologia] Re: Mengirim message panjang di linux
baskara wrote: On 2/11/06, adi [EMAIL PROTECTED] wrote: btw, boleh tahu kenapa harus pakai IP_HDRINCL? bermain-main dengan raw socket memang bermasalah kalau menghendaki program kita portable. Memakai IP_HDRINCL membuat kita lebih fleksibel dalam membuat header. Apalagi kalau membuat protokol baru. :-) Dalam kasus saya, ada IP option dan header baru yang saya tambahkan. Selain itu, saya juga bisa lebih mudah mengajari mhs2 lain tentang cara kerja IP. satu contoh penggunaan IP options yang infamous adalah Router Alert option : rfc 2113 dimana router harus closely examined/processed this packet (baca: masuk ke cpu untuk further processing) , harus dipakai di rsvp traffic-engineering message. sebenarnya kan jadi menarik, karena untuk router yg forwarding planenya hardware based (asic) jadi harus examine dan lookup tiap2 packet apakah ada ip router alert bitnya diset apa tidak.kalau harus lookup begini kan jadi ndak wire-rate performance. carlos --~--~-~--~~~---~--~~ Anda menerima pesan ini karena Anda tergabung pada grup Grup Google teknologia grup. To post to this group, send email to teknologia@googlegroups.com Untuk keluar dari grup ini, kirim email ke [EMAIL PROTECTED] Untuk pilihan lainnya, lihat grup ini pada http://groups.google.com/group/teknologia -~--~~~~--~~--~--~---
[teknologia] Re: Mengirim message panjang di linux
On 2/18/06, m.c. ptrwn [EMAIL PROTECTED] wrote: satu contoh penggunaan IP options yang infamous adalah Router Alert option : rfc 2113 dimana router harus closely examined/processed this packet (baca: masuk ke cpu untuk further processing) , harus dipakai di rsvp traffic-engineering message. He he he.. kerjaan saya pakai IP Router Alert Option kok. ;-) Tapi RFC 2113 itu nyaris tidak bercerita apapun. Mekanismenya terserah kita ya? Mengenai RSVP, aku lihat di dalam kernel BSD tidak menggunakan IPRA Option itu. Jadi langsung dideteksi di protocol id-nya. If ip-proto = RSVP then send to RSVP process. Di linux dan cisco, saya kurang tahu. --~--~-~--~~~---~--~~ Anda menerima pesan ini karena Anda tergabung pada grup Grup Google teknologia grup. To post to this group, send email to teknologia@googlegroups.com Untuk keluar dari grup ini, kirim email ke [EMAIL PROTECTED] Untuk pilihan lainnya, lihat grup ini pada http://groups.google.com/group/teknologia -~--~~~~--~~--~--~---
[teknologia] Re: Mengirim message panjang di linux
baskara wrote: On 2/18/06, m.c. ptrwn [EMAIL PROTECTED] wrote: satu contoh penggunaan IP options yang infamous adalah Router Alert option : rfc 2113 dimana router harus closely examined/processed this packet (baca: masuk ke cpu untuk further processing) , harus dipakai di rsvp traffic-engineering message. He he he.. kerjaan saya pakai IP Router Alert Option kok. ;-) Tapi RFC 2113 itu nyaris tidak bercerita apapun. Mekanismenya terserah kita ya? Yoi , terserah vendor , alias terserah C**co karena semua vendor mesti interop am C**co Mengenai RSVP, aku lihat di dalam kernel BSD tidak menggunakan IPRA Option itu. Jadi langsung dideteksi di protocol id-nya. If ip-proto = RSVP then send to RSVP process. Di linux dan cisco, saya kurang tahu. Korrekt ! Ponten 100 buat bang bas. Saya memang mengharapkan ada yang jawab pertanyaan implisit saya , jadi memang di embeded router, di asicnya ada statement yg pseudo codenya : if ip-proto == rsvpgo to cpu selain itu paket control plane lain (seperti ospf hello) juga diforward ke CPU. sedangkan packet-packet data diproces di ASIC. Carlos --~--~-~--~~~---~--~~ Anda menerima pesan ini karena Anda tergabung pada grup Grup Google teknologia grup. To post to this group, send email to teknologia@googlegroups.com Untuk keluar dari grup ini, kirim email ke [EMAIL PROTECTED] Untuk pilihan lainnya, lihat grup ini pada http://groups.google.com/group/teknologia -~--~~~~--~~--~--~---
[teknologia] Re: Mengirim message panjang di linux
On Sat, Feb 11, 2006 at 04:20:31PM +0900, baskara wrote: Menurut manpage of raw: Raw sockets fragment a packet when its total length exceeds the interface MTU (but see BUGS). btw, boleh tahu kenapa harus pakai IP_HDRINCL? bermain-main dengan raw socket memang bermasalah kalau menghendaki program kita portable. Salam, P.Y. Adi Prasaja
[teknologia] Re: Mengirim message panjang di linux
On 2/11/06, adi [EMAIL PROTECTED] wrote: btw, boleh tahu kenapa harus pakai IP_HDRINCL? bermain-main dengan raw socket memang bermasalah kalau menghendaki program kita portable. Memakai IP_HDRINCL membuat kita lebih fleksibel dalam membuat header. Apalagi kalau membuat protokol baru. :-) Dalam kasus saya, ada IP option dan header baru yang saya tambahkan. Selain itu, saya juga bisa lebih mudah mengajari mhs2 lain tentang cara kerja IP.
[teknologia] Re: Mengirim message panjang di linux
Punten Bang Baskara, saya malah tanya bukannya jawab. Gunanya mengirim message panjang di Linux yang Bang Baskara tanyakan ini untuk apa? Maaf ya kalau malah tambah bingung. Zaki Akhmad --~--~-~--~~~---~--~~ Anda menerima pesan ini karena Anda tergabung pada grup Grup Google teknologia grup. To post to this group, send email to teknologia@googlegroups.com Untuk keluar dari grup ini, kirim email ke [EMAIL PROTECTED] Untuk pilihan lainnya, lihat grup ini pada http://groups.google.com/group/teknologia -~--~~~~--~~--~--~---
[teknologia] Re: Mengirim message panjang di linux
On Fri, Feb 10, 2006 at 11:06:46PM +0900, baskara wrote: Akan tetapi, di linux (dalam hal ini saya coba di ubuntu), dengan cara yang sama persis, ini tidak bisa dilakukan (message too long katanya). saya kurang yakin, tapi coba set di /proc/sys/net/ipv4/ip_no_pmtu_disc. yang jelas, sendto() kalau dimaksudkan mengirimkan data secara 'atomic', maka tidak boleh melebihi ukuran MTU, karena akan mendapat EMSGSIZE. kecuali targetnya jelas freebsd/macosx, sebaiknya yang di atas itu diperhatikan :-) (biasa ada router perantara misalnya). Salam, P.Y. Adi Prasaja
[teknologia] Re: Mengirim message panjang di linux
On 2/11/06, adi [EMAIL PROTECTED] wrote: On Fri, Feb 10, 2006 at 11:06:46PM +0900, baskara wrote: Akan tetapi, di linux (dalam hal ini saya coba di ubuntu), dengan cara yang sama persis, ini tidak bisa dilakukan (message too long katanya). saya kurang yakin, tapi coba set di /proc/sys/net/ipv4/ip_no_pmtu_disc. yang jelas, sendto() kalau dimaksudkan mengirimkan data secara 'atomic', maka tidak boleh melebihi ukuran MTU, karena akan mendapat EMSGSIZE. Bagian yang itu belum saya ubah value-nya. Intinya, saya hanya ingin OS melakukan fragmentasi secara otomatis, seperti di BSD kernel. Jadi, kalau saya ingin mengirimkan 50KB JPEG file dengan UDP, saya cukup hanya membaca filenya, muat ke buffer, lalu kirim ke socket [ sendto() ]. Kernel saya harapkan secara otomatis mem-fragment 50KB data itu ke dalam paket2 berukuran max_mtu. Fragmentasi di user space sudah saya coba, gagal (as predicted) karena masalah buffering.
[teknologia] Re: Mengirim message panjang di linux
On Sat, Feb 11, 2006 at 07:47:08AM +0700, Budi Rahardjo wrote: On 2/11/06, baskara [EMAIL PROTECTED] wrote: Bagian yang itu belum saya ubah value-nya. Intinya, saya hanya ingin OS melakukan fragmentasi secara otomatis, seperti di BSD kernel. Jadi, kalau saya ingin mengirimkan 50KB JPEG file dengan UDP, Mungkin ini masalah lain, untuk meyakinkan bahwa datanya sampai dengan selamat apakah ada kendali (checksum, dll.) buatan sendiri? Hanya ingin tahu saja kenapa pakai UDP, nggak pakai TCP. Mungkin bisa lihat protokol FSP (FTP via UDP)? Kalo gak salah Pak Baskara projectnya berhubungan dengan streaming? Kalo untuk media streaming sepertinya low latency lebih penting drpd reliability selama jumlah dropped frames/packets masih acceptable. Jadi UDP kayaknya lebih cocok. CMIIW. Ronny signature.asc Description: Digital signature
[teknologia] Re: Mengirim message panjang di linux
On 2/11/06, Budi Rahardjo [EMAIL PROTECTED] wrote: Mungkin ini masalah lain, untuk meyakinkan bahwa datanya sampai dengan selamat apakah ada kendali (checksum, dll.) buatan sendiri? Checksum memang saya kalkulasi sendiri. Program saya tersebut bisa berjalan dengan baik di mesin mac os x dan freebsd (sebagai pengirim). Data yang saya kirim juga bisa sampai dengan selamat ke tujuan, bahkan saat melewati router (yang juga bsd machine). Pokoknya sudah well proven (di atas bsd box). Dengan ukuran datagram hingga 64KB, tidak ada masalah (kalau lebih dari 64KB harus saya pecah). Saat ingin saya jalankan juga di linux ini yang tampaknya tidak sesederhana di bsd. Hanya ingin tahu saja kenapa pakai UDP, nggak pakai TCP. Mungkin bisa lihat protokol FSP (FTP via UDP)? Data yang saya kirimkan itu kebanyakan berupa video data. Setiap 30 ms, saya kirim 1 frame yang rata-rata berukuran 10KB-60KB. Untuk keperluan ini, TCP tidak cocok, karena saya butuh speed dan tidak membutuhkan reliability. Kehilangan beberapa frames di jalan pun saya tidak peduli.
[teknologia] Re: Mengirim message panjang di linux
On Sat, Feb 11, 2006 at 09:12:45AM +0900, baskara wrote:
Bagian yang itu belum saya ubah value-nya. Intinya, saya hanya ingin
OS melakukan fragmentasi secara otomatis, seperti di BSD kernel. Jadi,
kalau saya ingin mengirimkan 50KB JPEG file dengan UDP, saya cukup
hanya membaca filenya, muat ke buffer, lalu kirim ke socket [ sendto()
]. Kernel saya harapkan secara otomatis mem-fragment 50KB data itu ke
dalam paket2 berukuran max_mtu.
hm.. iseng saya coba di 2 mesin (linux-ppc) satu ubuntu, lainnya debian
woody (kernel compile sendiri), nampaknya tidak ada isu signifikan,
berikut hasil strace:
sendto(3, \1\0\0\0\0BZh91AYSY\324\210\270\26\4\277|\177\377\377..., 32777,
0, {sin_family=AF_INET, sin_port=htons(1235), sin_addr=inet_addr(10.0.0.2)}},
16) = 32777
dalam program yang saya pakai, payload tidak boleh lebih dari +/- 64KB
coba di-strace atau kalau ada snippet code-nya :-)
Salam,
P.Y. Adi Prasaja
[teknologia] Re: Mengirim message panjang di linux
- Original Message - From: baskara [EMAIL PROTECTED] To: teknologia@googlegroups.com Sent: Saturday, February 11, 2006 1:12 AM Subject: [teknologia] Re: Mengirim message panjang di linux On 2/11/06, adi [EMAIL PROTECTED] wrote: On Fri, Feb 10, 2006 at 11:06:46PM +0900, baskara wrote: Akan tetapi, di linux (dalam hal ini saya coba di ubuntu), dengan cara yang sama persis, ini tidak bisa dilakukan (message too long katanya). saya kurang yakin, tapi coba set di /proc/sys/net/ipv4/ip_no_pmtu_disc. yang jelas, sendto() kalau dimaksudkan mengirimkan data secara 'atomic', maka tidak boleh melebihi ukuran MTU, karena akan mendapat EMSGSIZE. Bagian yang itu belum saya ubah value-nya. Intinya, saya hanya ingin OS melakukan fragmentasi secara otomatis, seperti di BSD kernel. Jadi, kalau saya ingin mengirimkan 50KB JPEG file dengan UDP, saya cukup hanya membaca filenya, muat ke buffer, lalu kirim ke socket [ sendto() ]. Kernel saya harapkan secara otomatis mem-fragment 50KB data itu ke dalam paket2 berukuran max_mtu. Fragmentasi di user space sudah saya coba, gagal (as predicted) karena masalah buffering. - Bisa cerita bagaimana masalah bufferingnya?
[teknologia] Re: Mengirim message panjang di linux
On 2/11/06, Ary Setijadi Prihatmanto [EMAIL PROTECTED] wrote: Bisa cerita bagaimana masalah bufferingnya? Sudah lupa error message-nya (buffer bla bla bla), tapi programnya sudah saya modifikasi dan masalah buffering itu sudah bisa diatasi. Fragmentasi di user space sudah bisa dilakukan, tapi masalahnya SPEED. Terlalu lambat. Setiap frame harus saya kirimkan dalam waktu 30 ms. Jadi tidak bisa realtime (jika dibandingkan dengan fragmentasi yang dilakukan oleh kernel). Btw. kelihatannya penyebab no fragmentation di kernel ini baru saja saya temukan. Menurut manpage of raw: Raw sockets fragment a packet when its total length exceeds the interface MTU (but see BUGS). Lalu, saya tengok BUGS: When the IP_HDRINCL option is set datagrams WILL NOT be fragmented and are limited to the interface MTU. Bah! :-( *puter otak lagi* # sysctl -w ikkyu-san_mode=1
