Incorporation of RANKL promotes osteoclast formation and osteoclast activity on β-TCP ceramics.

β-Tricalcium phosphate (β-TCP) ceramics are approved for the repair of osseous defects. In large defects, however, the substitution of the material by authentic bone is inadequate to provide sufficient long-term mechanical stability. We aimed to develop composites of β-TCP ceramics and receptor activator of nuclear factor κ-B ligand (RANKL) to enhance the formation of osteoclasts and promote cell mediated calcium phosphate resorption. RANKL was adsorbed superficially onto β-TCP ceramics or incorporated into a crystalline layer of calcium phosphate by the use of a co-precipitation technique. Murine osteoclast precursors were seeded onto the ceramics. After 15 days, the formation of osteoclasts was quantified cytologically and colorimetrically with tartrate-resistant acidic phosphatase (TRAP) staining and TRAP activity measurements, respectively. Additionally, the expression of transcripts encoding the osteoclast gene products cathepsin K, calcitonin receptor, and of the sodium/hydrogen exchanger NHA2 were quantified by real-time PCR. The activity of newly formed osteoclasts was evaluated by means of a calcium phosphate resorption assay. Superficially adsorbed RANKL did not induce the formation of osteoclasts on β-TCP ceramics. When co-precipitated onto β-TCP ceramics RANKL supported the formation of mature osteoclasts. The development of osteoclast lineage cells was further confirmed by the increased expression of cathepsin K, calcitonin receptor, and NHA2. Incorporated RANKL stimulated the cells to resorb crystalline calcium phosphate. Our in vitro study shows that RANKL incorporated into β-TCP ceramics induces the formation of active, resorbing osteoclasts on the material surface. Once formed, osteoclasts mediate the release of RANKL thereby perpetuating their differentiation and activation. In vivo, the stimulation of osteoclast-mediated resorption may contribute to a coordinated sequence of material resorption and bone formation. Further in vivo studies are needed to confirm the current in vitro findings.

Synchronizing sound from different devices over a TCP network

Nowadays, we can send audio on the Internet for multiples uses like telephony, broadcast audio or teleconferencing. The issue comes when you need to synchronize the sound from different sources because the network where we are going to work could lose packets and introduce delay in the delivery. This can also come because the sound cards could be work in different speeds. In this project, we will work with two computers emitting sound (one will simulate the left channel (mono) of a stereo signal, and the other the right channel) and connected with a third computer by a TCP network. The last computer must get the sound from both computers and reproduce it in a speaker properly (without delay). So, basically, the main goal of the project is to synchronize multi-track sound over a network. TCP networks introduce latency into data transfers. Streaming audio suffers from two problems: a delay and an offset between the channels. This project explores the causes of latency, investigates the affect of the inter-channel offset and proposes a solution to synchronize the received channels. In conclusion, a good synchronization of the sound is required in a time when several audio applications are being developed. When two devices are ready to send audio over a network, this multi-track sound will arrive at the third computer with an offset giving a negative effect to the listener. This project has dealt with this offset achieving a good synchronization of the multitrack sound getting a good effect on the listener. This was achieved thanks to the division of the project into several steps having constantly a good vision of the problem, a good scalability and having controlled the latency at all times. As we can see in the chapter 4 of the project, a lack of synchronization over c. 100μs is audible to the listener. RESUMEN. A día de hoy, podemos transmitir audio a través de Internet por varios motivos como pueden ser: una llamada telefónica, una emisión de audio o una teleconferencia. El problema viene cuando necesitas sincronizar ese sonido producido por los diferentes orígenes ya que la red a la que nos vamos a conectar puede perder los paquetes y/o introducir un retardo en las entregas de los mismos. Así mismo, estos retardos también pueden venir producidos por las diferentes velocidades a las que trabajan las tarjetas de sonido de cada dispositivo. En este proyecto, se ha trabajado con dos ordenadores emitiendo sonido de manera intermitente (uno se encargará de simular el canal izquierdo (mono) de la señal estéreo emitida, y el otro del canal derecho), estando conectados a través de una red TCP a un tercer ordenador, el cual debe recibir el sonido y reproducirlo en unos altavoces adecuadamente y sin retardo (deberá juntar los dos canales y reproducirlo como si de estéreo de tratara). Así, el objetivo principal de este proyecto es el de encontrar la manera de sincronizar el sonido producido por los dos ordenadores y escuchar el conjunto en unos altavoces finales. Las redes TCP introducen latencia en la transferencia de datos. El streaming de audio emitido a través de una red de este tipo puede sufrir dos grandes contratiempos: retardo y offset, los dos existentes en las comunicaciones entre ambos canales. Este proyecto se centra en las causas de ese retardo, investiga el efecto que provoca el offset entre ambos canales y propone una solución para sincronizar los canales en el dispositivo receptor. Para terminar, una buena sincronización del sonido es requerida en una época donde las aplicaciones de audio se están desarrollando continuamente. Cuando los dos dispositivos estén preparados para enviar audio a través de la red, la señal de sonido multi-canal llegará al tercer ordenador con un offset añadido, por lo que resultará en una mala experiencia en la escucha final. En este proyecto se ha tenido que lidiar con ese offset mencionado anteriormente y se ha conseguido una buena sincronización del sonido multi-canal obteniendo un buen efecto en la escucha final. Esto ha sido posible gracias a una división del proyecto en diversas etapas que proporcionaban la facilidad de poder solucionar los errores en cada paso dando una importante visión del problema y teniendo controlada la latencia en todo momento. Como se puede ver en el capítulo 4 del proyecto, la falta de sincronización sobre una diferencia de 100μs entre dos canales (offset) empieza a ser audible en la escucha final.

Comunicación con RS-485 y MODBUS

Práctica 3. Comunicación con RS-485 y MODBUS.

Cluster scheduling and load balancing via TCP options

This paper describes an experiment in designing, implementing and testing a Transport layer cluster scheduling and dispatching architecture. The motivation for the experiment was the hypothesis that a Transport layer clustering solution may offer advantantages over the existing industry-standard Network layer and Data Link Layer approaches. The critical success factors initially established to guide and evaluate the experiment were reduced dispatcher work load, reduced dispatcher internal state memory requirements, distributed denial of service resilience, and cluster software design simplicity. The functional design stage of the experiment produced a Transport layer strategy for scheduling and load balancing based on the specification of two new TCP options. Implementation required the introduction of the newly specified TCP options into the Linux (2.4) kernel. The implementation produced an extended Linux Socket API to facilitate user-process access to the additional TCP capability. The testing stage of the experiment confirmed the operational efficiency of the solution.

Examining TCP parallelization related methods for various packet losses

The diversity of the networks (wired/wireless) prefers a TCP solution robust across a wide range of networks rather than fine-tuned for a particular one at the cost of another. TCP parallelization uses multiple virtual TCP connections to transfer data for an application process and opens a way to improve TCP performance across a wide range of environments - high bandwidth-delay product (BDP), wireless as well as conventional networks. In particular, it can significantly benefit the emerging high-speed wireless networks. Despite its potential to work well over a wide range of networks, it is not fully understood how TCP parallelization performs when experiencing various packet losses in the heterogeneous environment. This paper examines the current TCP parallelization related methods under various packet losses and shows how to improve the performance of TCP parallelization.

Increased availability and scalability for clustered services via the wait time calculation, trust based filtering and redirection of TCP connection requests

The paper describes two new transport layer (TCP) options and an expanded transport layer queuing strategy that facilitate three functions that are fundamental to the dispatching-based clustered service. A transport layer option has been developed to facilitate. the use of client wait time data within the service request processing of the cluster. A second transport layer option has been developed to facilitate the redirection of service requests by the cluster dispatcher to the cluster processing member. An expanded transport layer service request queuing strategy facilitates the trust based filtering of incoming service requests so that a graceful degradation of service delivery may be achieved during periods of overload - most dramatically evidenced by distributed denial of service attacks against the clustered service. We describe how these new options and queues have been implemented and successfully tested within the transport layer of the Linux kernel.