What is advantage of Redis Data Structured Server

Topic : 

Redis data structured server  and sample code , use cases . 

Following essential points , why do we need Redis 

-- Ease of store  and cache key - value pairs 

-- Inbuilt use of  in memory (i.e)  Redis use  memory mapped techniques

-- The key - value cached  values never get lost , as Redis used MMAP concepts 

-- REDIS runs over TCP, UDP , UNIX Domain socket 

-- You can configure Redis either in your local host , or in remote server 

-- Hence Redis shall be called as  Centralized Remote Data Structured Server 

--   Redis has different data types , and has DATABASE similar to other SQL servers 

-- you can create your own data base and have key value mapping stores per data base ... 

--- The data base can be switched to other 

-- Very simple way of doing  SET, GET method to read and write 'key - value ' into redis database server 

-- You can configure redis configuration file , for optimized memory and data base configurations 

Applications  use case of interest 

--- To Maintain centralized unique key value pair

--- Dynamic way of generating unique key and store  value (as input from user) 

Example: 

 You have some data to be stored uniquely across your networks. 

Redis can create you unique key, you shall store your data with that unique key . 

Typically  Redis shall be applied on  User Sessions Accounting,  File Management,  Choosing File with suffix as key, 

Web Caching Contents (file naming as unique key). 

FEEL FREE TO COMMENT FOR CLARIFICATIONS.

 

NetBSD DHCP Client Optimization to discover interfaces

Hi , 

Here is some information about  Internet Systems Consortium (ISF) dhcp client software

ISF DHCP Client software has dhcp client statemachine , well written to acquire ip address for multiple interfaces. 

It maintains three different interface  list for maintain the interface where dhcp client enabled . 

The interface database (list) are 

(a) interfaces 

(b) dummy_interfaces 

(c) fallback_interfaces

Here my share on optimization of discover_interfaces function.

This topic would be used those who are using ISF dhcp client library,  to achieve ip address assignment via dhcp 

discover_interfaces 

-- This function mainly to walk through the interfaces database and get the interfaces who are looking for ip address 

-- In the whole library discover_interfaces function , called for multiple times with different state 

DISCOVER

REQUESTED 

UNCONFIGURED  and so on..

-- I have removed many of the calling places 

-- And introduced passing the interface index as input to discover_interfaces function

--- By this way  i achieved following 

 (a) For every state transition you dont need  to call discover_interfaces 

(b)  During initialization also no need to call discover_interfaces 

(c) The effective use passing interface index solved looking at interface details from the database 

   Instead of walking though the entire interfaces in the system and find out what are interfaces looking for ip address 

--- Two things are achieved ,

1. Calling many times discover_interfaces  (optimized passing interface index and do discover only for the given interface )

2.  Achieved  less CPU Memory Utilization.. 

By this optimization i could able to have more number of interfaces shall able to  get ip address using ISF DHCP Client library. 

IF YOU HAVE ANY COMMENTS ARE CLARIFICATION NEEDED PLEASE FEEL FREE TO COMMENT 

Optimized Receive Buffer on socket descriptor while select socket operation

The optimized way of receiving the data on the socket while doing select.

Scenario :


-- Do select on  "N" number of file descriptors,  based on the FD_ISSET do receive the packet buffer.

-- what happens when there are packets are in stream, (i.e) they are just yet to be copied to socket receive buffer by linux kernel.

-- Obviously after processing the packet, the control go back to select operation


-- Thus having more packets written to the  socket receive buffer during burst scenario, the socket buffer will get full and packets will be lost


-- The optimized approach is to, do  IOCTL call to that socket fd, and get the available receive buffer length  before doing receive packet buffer.

-- Its very optimistic way recently i have experienced this approach..


-- It works pretty cool..

--  you would need to add your code in kernel  soo_ioctl function.. get the struct socket  so_rcv.sb_cc -- i.e length of socket receive buffer

Debugging corrupted stack

Hi,

recently i have experienced having corrupted stack frames.

Its multi threaded environment..

My process got crashed due to stack overflow.


You have memset call where the size you are not initialized .

example:

int n;
char buf[100];

memset(buf, 0, n) ;

(gdb) bt
#0 0x0183e4c8 in byte32sse2 ()
#1 0xb1036f68 in ?? ()
#2 0x00001b98 in ?? ()
#3 0x0183ba51 in _intel_fast_memset ()
#4 0xb1036e10 in ?? ()
#5 0x00000000 in ?? ()
(gdb)    


this is how the intel memset thread stack trace shows. 


It would be difficult to find out, in a process where do you missed to initialize the size n. 


The best approach. 

Run gdb  check for 

 esp  -- top of stack pointer. 

use objectdump -sSLdx  <process binary> 


save the output to a file 

run gdb check for esp 

x/32gwa $esp 

it would possible give the some traces. 

go over the address in the esp 

esp is the top of the stack frame.  

search the address in the  output of objectdump utility. You shall get some clue on  Root Caused. 

compile symbolic file in makefile

I just come across Makefile built in rule to compile symbolic file.

SRCS       =  a.c $(LINKED_SRCS)
endif

# ++ linked source
LINKED_SRCS= b.c

${LINKED_SRCS} links:  linkstamp

cleanlinks:
    @ - rm -f ${LINKED_SRCS} linkstamp

linkstamp:
    @ - rm -f ${LINKED_SRCS}
    ln -sf $(PROJECTDIR)/SRC/UsrLib_src/b.c b.c
    touch linkstamp



- This rule works, based on your linkstamp file, say if linkstamp file present - Makefile consider that symbolic link already presence.

-This rule will be executed before compiling b.c

-since b.c has links attached -- so b.c will not be compiled before link creation

step:1 -- compile a.c
step:2 -- create links
step 3: -- compile b.c

very interesting about links:

Programmer should know about memory

Hereby am sharing some of points about modern memory architecture

- Intel Hyper-threading enabled single processor core to be used for two or more concurrent executions with just little extra hardware

how exec system call works

Interesting implementation of parallel file upload and do socket polling 

Scenario  you need to look for the incoming data, and do ftp file upload. 

From C program you can invoke exec system call to do ftp file upload 

For FTP  either you can use CURL library  / linux / some other libraries .  I recommend CURL, i've been working on this quite a time.

Lets say:  I've a process  created thread in it ,doing socket select operations , 

               when i receive some X message i need to do file upload. 

Better approach: 

From your packet handler thread , spawn process  obliviously do "fork" , let child process do ftp file upload, parent wait for child to complete file upload. 

After file upload child process exited, followed by process detached . 

Here there is no interruption with packet handler routine, since both packet handling and ftp file upload runs in different process context .. so kernel would take care of scheduling them.. As application we achieving parallelism by this approach. 

Exec : system call could be used to  execute your binary inherit from process that has invoked, meaning exec system call replace current process context with new one. 

For this scenario,  "packet handling & ftp file upload post receive message" -- exec system call in new process context is best approach to achieve. 

Exec system call could be used in different scenarios w.r.t requirements.