Please enable JavaScript.

Coggle requires JavaScript to display documents.

Netty (ByteBuf (Why ByteBuf? (2 pointers, readerIndex & writerIndex…

- - - - discardReadBytes can free data in [0, readerIndex] and shift readable bytes to the beginning of buffer
      - to track data and read position in buffer separately
      - no more flip()!
    - - return a ByteBuf that share the buffer but has separate read/write index
    - - return a copy of the ByteBuf, totally separate one
    - - return a ByteBuf from readIndex to writeIndex, share the same buffer but separate index
    - - convert to NIO ByteBuffer
      - it does NOT recognise resizing of source ByteBuf
    - - set
      - get
    - - forward readerIndex by length, throws if it's beyond writerIndex after skip
  - - - fast memory allocation/revoke, JVM GC handles it
      - if using Socket IO, extra memory copy of head <---> channel
      - :star: better in encoding/decoding buffer
      - stores as byte[] on heap, use hasArray() to check if it's HeapByteBuf
    - - use off-heap memory, slower memory alloc/revoke
      - faster Socket Channel read/write, no extra mem copy
      - :star: better in Channel I/O
    - - reused in a pool
      - :star: recommended
      - reduce GC frequency
      - introduce cost of managing the pool
      - PoolArena
        
        implementation of Netty mem pool
        
        a large continuous memory area requested initially
        
        in Netty, PoolArena consists of many Chunks, each Chunk has many Pages
        
        Chunk
        
        manage allocate/revoke Pages in memory.
        mark a branch node as used if all Pages under it has been used
        
        Pages built as BinaryTree
        
        64 bytes each, consists of 16 Pages
        
        DFS with randomly choosing a node to visit
        
        Page
        
        4 bytes each
        
        SubPage
        
        split a Page into blocks, size based on first allocation.
        e.g. a 8 byte Page is split into 2 * 4 bytes SubPages if
        4 bytes are allocated on first time
    - - UnpooledHeapByteBuf
        
        create new instance each time, can impact GC
        
        cheaper than allocating off-heap memory
        
        simple implementation
        
        :star: recommended if performance meets requirement
        
        use byte[] as buffer
        
        tmpNioBuf for converting to NIO ByteBuffer, reset to null after buffer resizing
    - - view of multiple underlying ByteBuf's, allow dynamically add/remove ByteBuf's
  - - - ReferenceCounted is essence
  - - - read file by chunk when zero-copy is not supported, or you need to transform file data
    - - transfer chunks from ReadableByteChannel
    - - transfer chunks from InputStream
    - - similar to ChunkedFile but using NIOFileChannel
    - - add this before ChunkedStream handlers to write chunked input data in outbound
- - - - read data to inbound buffer
      - trigger ChannelHandler.channelRead(ChannelHandlerContext, Object) callback
      - then trigger channelReadComplete(context)
    - - write msg thru ChannelPipeline to channel.
      - NOT sent until called flush()
    - - close connection, handle close result via the promise
      - will trigger close() on each handler in the pipeline
    - - request disconnection
      - trigger disconnect() on each handler in the pipeline
    - - connect to address
      - trigger connect() on all handler in the pipeline
    - - bind local port
      - trigger bind() on all handler in the pipeline
    - - get the selector this channel registered to
    - - get TCP config
    - - null for server channel
      - the server channel for this client channel
  - - - SocketChannel.read() get ByteBuf and trigger ChannelRead event ->
        NioEventLoop select the ChannelRead event ->
        NioEventLoop call ChannelPipeline.fireChannelRead(Object msg) ->
        NioEventLoop send ByteBuf to ChannelPipeline ->
        Handlers process ByteBuf in turn, any one can terminate it ->
      - triggered by user client
    - - ChannelHandlerContext.write() ->
        ByteBuf travel thru pipeline in reverse order to reading ->
        Message is written to sending buffer, wait to be sent by flush()
      - triggered by ChannelHandlerContext
  - - - ChannelHandler can be shared by many pipelines
    - - method with @Skip will not be called
    - - decode(ChannelHandlerContext, ByteBuf, List<Object>)
      - if cannot decode with current buffer state, reset readIndex and quit decoding
    - - prepend length before message
    - - HeadHandler
      - TailHandler
  - - - ctx.fireXXX() methods handle the event with handler in current context (only if the handler has been fully initialized)
        
        find next capable handler (inbound or outbound) in the pipeline and call the same fireXXX method on it.
      - other fireXXX methods invoke next call on the next handler in the pipeline
      - if the executor thread of next handler is in event loop, use current thread to call the fireXXX method.
        Otherwise use the executor of the next handler itself to call
- - - - resize buffer according to actual read bytes
- - - - FileChannel
      - DatagramChannel
      - SockerChannel
      - ServerSockerChannel
    - - transferFrom(sourceChan, position, count)
      - transferTo(position, count, targetChan)
  - - - channel() - get channel associated with the selKey
      - selector() - get selector associated with the selKey
      - attach(obj) - attach an object to a selKey
      - attachment() - get the attached obj
    - - select() - blocks until a channel is ready for the events registered
      - select(timeout) - block upto timeout
      - selectNow() - return immediately with whatever channels ready
      - selectedKeys() - once the select methods return > 0, get a Set<SelectionKey> of ready selections
      - use iterator to iterate thru the selKeys. MUST remove each selKey by iterator.remove() after iterating it.
      - you need to cast the channel from SelectionKey.channel() to proper type
      - wakeUp() - resume a thread that is waiting on a select(). must be called from another thread
      - close() - close the selector, invalidates all selectionKeys registered. Channels are not closed
      - http://tutorials.jenkov.com/java-nio/selectors.html
  - - - reads data from a channel into multiple buffers
      - reads into buffers in order as they appear in the array
      - once a buffer is full, move on reading into next buffer
      - NOT for dynamic data length, need to know the fixed size beforehand
    - - writes data from multiple buffers into a single channel
      - writes in order as buffers in the array
      - only writes data in between position and limit
      - works fine with dynamic sized data
- - - - send/recv TCP connections
      - read request/response from connection
      - write request/response to connection
      - all I/O on a single thread
    - - receive TCP Connections
    - - send ByteBuffer to corresponding Handler after connection done
    - - 1 Acceptor thread listen to new connection :!: bottleneck
      - NIO thread pool handle I/O, reading/decoding/encoding/sending data
    - - NIO thread pool for Acceptors
      - Acceptor accept TCP conn, verify, auth, create SocketChannel and register to I/O thread pool
      - :star: recommended
  - - - NioEventLoop.execute(Runnable task) - put user tasks to I/O thread pool to avoid lock contention
    - - NioEventLoop.schedule(Runnable task, long delay, TimeUnit unit)
  - - - boss group
        
        notify conn state change to ChannelPipeline
        
        accept TCP conn, initialise Channel config
      - worker group
        
        async send data to conn, via ChannelPipeline in reverse
        
        async read data from conn, fire event to ChannelPipeline
    - - #thread = (total_thread_time / bottleneck_resource_time) * bottleneck_concur_thread_count
      - QPS = 1000 / total_thread_time * #threads
  - - - replace selectedKeys with selectedKeySet using reflection
    - - fixed JDK empty-epoll bug - 6403933
      - if > N empty-epoll within 100ms, it's the bug, rebuild selector by
        openSelector() to create a new one,
        register events on old selector to new one and deregister from old one,
        close old one
- - - - addListener(listener)
        
        I/O thread call listener.operationComplete() to process future result
      - await()
        
        :!:DO NOT call ChannelFuture.await() in ChannelHandler,
        will cause deadlock if I/O thread and user thread are the same, where the thread is waiting to be notified by itself
      - :!:be careful: ChannelFuture timeout != I/O timeout
        conn can succeed after future timeout
        always close() properly
  - - - wait for future to complete, rethrow the cause if future failure