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.

Perforce Commands

Basic Commands:

P4 opened

function to set p4 client

function p4client()

{

        if [ -z $1 ]; then

                curr=`pwd`

                base=`basename $curr`

        else

                base=$1

        fi

        export P4PORT="p4sw1:1666"

        export P4USER="ssankar"

        export P4CLIENT="$base"

        export F10MKVERBOSE=1

}

P4 diff  <file>  or p4 diff – full diff

P4 revert <filename>

P4 submit –c <changelist no>

#save changelist (cl> to p4 server then pathc in other client

P4 shelve –c <cl no>

P4 unshelve –s <changelist no>

#delete p4 shelve

P4 shelve –d –c <changelistno>

 p4 client -d <clientname>

  

If you facing problem in deleting P4 Client ,  check for pending change list associated with P4 Client ,  revert the changes or you can delete forcibly if you have admin permission

p4 client -d  <p4clietn name>

p4 changes -c  <client-name> -s pending

p4 change -d <clno>

 p4 client -d <client-name>