Mañas de los scripts

Para no olvidar: Si empiezas un script con un comentario obtienes un mesaje de error "Cannot execute binary file" al ejecutarlo desde otro script. Así que para quitarse de problemas hay que iniciarlo con #!/bin/sh, que por cierto ya aprendí que no es nada más para que se vea más "apantallante" el script, sino que sirve para que los comandos se ejecuten en un nuevo shell. Hablando de eso, si ejecutas un script con esta notación:

. [nombredelscript]

entonces los comandos se ejecutan en el shell actual (esto es útil si quieres que se conserve alguna variable de shell al terminar la ejecución del script). Con esa notación ya no se toma en cuenta el #!/bin/sh (no se crea un nuevo shell)

.o files

.o files can be created with the following command:

g++ -c [program.cpp]

To create the executable file

g++ [program.cpp] -o program

Segmentation fault!

Nunca se me va a olvidar:

EL NOMBRE DE UN ARREGLO ES UN APUNTADOR... ¡DEL TIPO E S T Á T I C O!!
¡Osea que lo puedes usar para LEER los elementos mas no para modificarlos!
Esto lo aprendí después de un buen rato de sufrimiento con un SEGMENTATION FAULT!

Vmstat

Definitivamente el comando del día... Permite obtener estadísticas sobre el uso del CPU, la memoria y... Los procesos creados.
Ejemplo:
# vmstat

vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 16 45816 231168 243392 0 0 15 11 524 812 13 2 84 0

Para ver el número de forks() se escribe:

# vmstat -f
6721 forks

Consideraciones en cuanto a fork()

Excelente documento que explica consideraciones de rendimiento del fork() y el scheduler de Linux 2.4.

http://bulk.fefe.de/scalable-networking.pdf

POSIX

POSIX = (Portable Operating System Interface)

POSIX (Portable Operating System Interface) is a set of standard operating system interfaces based on the Unix operating system.

Conjunto de interfaces estándares para sistemas operativos, basados en el sistema operativo UNIX.
POSIX.1 - Estándar API en C
POSIX.2 - Shell
POSIX.4 - Threads

Límites del sistema

Un comando muy útil en Linux es ulimit, ya que permite controlar los recursos disponibles para el shell y para los procesos comenzados por él, en sistemas que permitan ese tipo de control.

- Numero máximo de procesos del usuario
- Tiempo máximo de uso en el CPU
etc.

Ejemplo:

ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u) 8187
virtual memory (kbytes, -v) unlimited

La siguiente es una sugerencia para cambiar estos parámetros:

On Sun, May 02, 1999 at 08:48:42AM -0700, David S Edwards wrote:
This isn't bash, this is the linux kernel:

--BEGIN: /usr/src/linux/include/linux/tasks.h:
MAX_TASKS_PER_USER is later used to determine the default ulimit
(which is independant of bash. See setrlimit(2)). A normal user can't
ever raise his limit, and /etc/profile runs as the user, so you can't
fix it there. The only solution I know is to change tasks.h and
recompile your kernel.

Para ver/cambiar estos límites a nivel de código:
man setrlimit

Problema con select

Estoy teniendo un problema al utilizar el select. Al parecer detecta correctamente cuando alguno de los sockets se encuentra listo para recibir datos. Sin embargo, de los 832000 bytes que intento mandar, solamente lee los primeros 1447 bytes (así es, el tamaño del MTU). Esto quiere decir que solamente alcanza a leer el primer datagrama. Hice muchas pruebas y el problema persistió, así que opté por utilizar fork() para crear nuevos procesos que atiendan al cliente. Al parecer de esta forma consigo que varios clientes puedan estar enviando datos al servidor al mismo tiempo. Supuestamente el único lapso en el que no se atendería a un cliente es en lo que se hace la llamada a fork(), por lo que quizá sea útil para mi propósito.

Algo que me llamó la atención sobre el uso de select es lo siquiente:

Stevens(from memory) "when faced with the choice of using non-blocking i/o or threads/processes, the smarter decision is threads/procesesses." reasons:
*non blocking i/o is difficult to implement and error prone.
*the behavior of select with non blocking descriptors is platform specific. so you need added code to handle these differences
*threads/forks()'s are only a fraction of the time slower, and much easier to implement

Esto lo tomé de un foro (http://forums.devshed.com/t93193/s.html) en donde recomienda el siguiente libro:

Unix network programming volume 1 by w richard stevens

En fin, hasta el momento parece ser que he conseguido mi propósito, ahora faltará observar algunas cuestiones de rendimiento.

ILA

Tutorial de sockets

Tutorial de sockets en español, con un lenguaje más directo.
http://www.arrakis.es/~dmrq/beej/

Driver Modem

Una alternativa a Linuxant:

http://downloadfinder.intel.com/scripts-df/
filter_results.asp?strOSs=39&strTypes=DRV&ProductID=1230&OSFullName=Linux*&submit=Go%21

Ing...

Ahora si, por fin soy Ingeniera en Sistemas Computacionales ;)

Netperf

Herramienta para el diagnóstico del rendimiento de una red. Puede ser bajado desde www.netperf.org

First

Gmail rocks! ;)