good morning!!!!

Skip to content
Snippets Groups Projects
  1. May 14, 2015
  2. May 13, 2015
    • Felix Lange's avatar
      Merge pull request #966 from fjl/fixup-discover-chunked-neighbors · f7fdb4df
      Felix Lange authored
      p2p/discover: fix out-of-bounds slicing for chunked neighbors packets
      f7fdb4df
    • Felix Lange's avatar
      p2p/discover: fix out-of-bounds slicing for chunked neighbors packets · 251846d6
      Felix Lange authored
      The code assumed that Table.closest always returns at least 13 nodes.
      This is not true for small tables (e.g. during bootstrap).
      251846d6
    • Jeffrey Wilcke's avatar
      Merge pull request #963 from Gustav-Simonsson/fix_keystore_crypto_comments · fad21fb4
      Jeffrey Wilcke authored
      Update keystore code comments
      fad21fb4
    • Felix Lange's avatar
      Merge pull request #965 from subtly/patch-1 · b2119d89
      Felix Lange authored
      Better UDP & interop. Limit all received datagrams to 1280bytes.
      b2119d89
    • Alex Leverington's avatar
      fix test. · 8eef2b76
      Alex Leverington authored
      8eef2b76
    • Alex Leverington's avatar
    • Alex Leverington's avatar
      UDP Interop. Limit datagrams to 1280bytes. · 7473c936
      Alex Leverington authored
      We don't have a UDP which specifies any messages that will be 4KB. Aside from being implemented for months and a necessity for encryption and piggy-backing packets, 1280bytes is ideal, and, means this TODO can be completed!
      
      Why 1280 bytes?
      * It's less than the default MTU for most WAN/LAN networks. That means fewer fragmented datagrams (esp on well-connected networks).
      * Fragmented datagrams and dropped packets suck and add latency while OS waits for a dropped fragment to never arrive (blocking readLoop())
      * Most of our packets are < 1280 bytes.
      * 1280 bytes is minimum datagram size and MTU for IPv6 -- on IPv6, a datagram < 1280bytes will *never* be fragmented.
      
      UDP datagrams are dropped. A lot! And fragmented datagrams are worse. If a datagram has a 30% chance of being dropped, then a fragmented datagram has a 60% chance of being dropped. More importantly, we have signed packets and can't do anything with a packet unless we receive the entire datagram because the signature can't be verified. The same is true when we have encrypted packets.
      
      So the solution here to picking an ideal buffer size for receiving datagrams is a number under 1400bytes. And the lower-bound value for IPv6 of 1280 bytes make's it a non-decision. On IPv4 most ISPs and 3g/4g/let networks have an MTU just over 1400 -- and *never* over 1500. Never -- that means packets over 1500 (in reality: ~1450) bytes are fragmented. And probably dropped a lot.
      
      Just to prove the point, here are pings sending non-fragmented packets over wifi/ISP, and a second set of pings via cell-phone tethering. It's important to note that, if *any* router between my system and the EC2 node has a lower MTU, the message would not go through:
      
      On wifi w/normal ISP:
      localhost:Debug $ ping -D -s 1450 52.6.250.242
      PING 52.6.250.242 (52.6.250.242): 1450 data bytes
      1458 bytes from 52.6.250.242: icmp_seq=0 ttl=42 time=104.831 ms
      1458 bytes from 52.6.250.242: icmp_seq=1 ttl=42 time=119.004 ms
      ^C
      --- 52.6.250.242 ping statistics ---
      2 packets transmitted, 2 packets received, 0.0% packet loss
      round-trip min/avg/max/stddev = 104.831/111.918/119.004/7.087 ms
      localhost:Debug $ ping -D -s 1480 52.6.250.242
      PING 52.6.250.242 (52.6.250.242): 1480 data bytes
      ping: sendto: Message too long
      ping: sendto: Message too long
      Request timeout for icmp_seq 0
      ping: sendto: Message too long
      Request timeout for icmp_seq 1
      
      
      Tethering to O2:
      localhost:Debug $ ping -D -s 1480 52.6.250.242
      PING 52.6.250.242 (52.6.250.242): 1480 data bytes
      ping: sendto: Message too long
      ping: sendto: Message too long
      Request timeout for icmp_seq 0
      ^C
      --- 52.6.250.242 ping statistics ---
      2 packets transmitted, 0 packets received, 100.0% packet loss
      localhost:Debug $ ping -D -s 1450 52.6.250.242
      PING 52.6.250.242 (52.6.250.242): 1450 data bytes
      1458 bytes from 52.6.250.242: icmp_seq=0 ttl=42 time=107.844 ms
      1458 bytes from 52.6.250.242: icmp_seq=1 ttl=42 time=105.127 ms
      1458 bytes from 52.6.250.242: icmp_seq=2 ttl=42 time=120.483 ms
      1458 bytes from 52.6.250.242: icmp_seq=3 ttl=42 time=102.136 ms
      7473c936
    • Gustav Simonsson's avatar
      Update keystore code comments · 56a5592e
      Gustav Simonsson authored
      56a5592e
    • Péter Szilágyi's avatar
      Merge pull request #954 from karalabe/fix-downloader-nil-panic · 3edc4698
      Péter Szilágyi authored
      eth/downloader: fix nil panic caused by wrong variable use
      3edc4698
    • Péter Szilágyi's avatar
    • Jeffrey Wilcke's avatar
      Merge pull request #948 from karalabe/fix-downlaoder-activepeer-shadow · 7cb0e242
      Jeffrey Wilcke authored
      eth/downloader: fix active peer shadowing, polish func names
      7cb0e242
    • Péter Szilágyi's avatar
    • Jeffrey Wilcke's avatar
      Merge pull request #946 from Gustav-Simonsson/fix_geth_unlock_account · 6dec9046
      Jeffrey Wilcke authored
      Fix hex conversion in --unlock and log when successful
      6dec9046
  3. May 12, 2015
Loading