多线程udp服务器 [英] Multithreaded udp server

查看:256
本文介绍了多线程udp服务器的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我是新来的线程,请给我建议.我有广播消息的服务器 给客户.然后,客户端将答复发送回服务器.我想使用 单独的线程.每个答复将具有消息ID和线程ID.我该如何填充一些结构 从所有线程获取这些信息,然后阅读

I'm new with threads and please if you can advice me. I have server that broadcast messages to clients. Then clients sends back replies to server. I want to handle every reply using seperate thread. Every reply will have mesage id and thread id. How can I fill some structure with this information from all threads and then read it

同样从我的代码中,是否可以在while中正确创建线程,或者它是否以某种方式存在 创建线程,就算我得到客户的答复?

Also from my code, is it correctly to create thread in while or does it exist someway to create thread just if I get reply from client?

我是从正确的理解开始的吗?

Did I start with correct understanding?

int main(){

    while(1){

        sendto on broadcast IP 
        pthread_create(&cln_thread, NULL, msg_processing, (void *) &arg))

   }
}

msg_processing () {

     recvfrom client msg with id of packet and thread id
     how to write those informations and then read them in main when program finish

}

谢谢

推荐答案

Err ..否,仅创建一个线程(仅一次)以在一个套接字上接收数据报.在线程函数中,在while(true)循环中接收数据报.不要让此接收线程终止,也不要创建更多的接收线程.不断创建/终止/销毁线程效率低下,危险,不必要,容易出错,难以调试,因此您应该努力不做.

Err.. no, just create ONE thread, once only, for receiving datagrams on one socket. In the thread function, receive the datagrams in a while(true) loop. Don't let this receive thread terminate and don't create any more receive threads. Continually creating/terminating/destroying threads is inefficient, dangerous, unnecessary, error-prone, difficult-to-debug and you should try very hard to not do it, ever.

仅一个接收线程-但您不必在那里进行处理. Malloc分配一个64K缓冲区,将数据接收到其中,将缓冲区指针推到生产者-消费者队列上,到达将进行处理的线程池,然后循环返回,因此malloc再次重置该指针并为下一个数据报创建另一个缓冲区.处理完成后,释放池线程中的* buffer.缓冲区同时运行时,接收线程将迅速返回以等待数据报.

One receive thread only - but you don't have to do the processing there. Malloc a 64K buffer, receive data into it, push the buffer pointer onto a producer-consumer queue to a pool of threads that will do the processing, loop back and so malloc again to reseat the pointer and create another buffer for the next datagram. Free the *buffers in the pool threads after the processing is completed. The receive thread will be back waiting for datagrams quickly while the buffer processing runs concurrently.

如果您发现数据报的到达速度如此之快以至于处理无法跟上,那么随着队列中堆积越来越多的* buffer,内存使用将不受限制地增长.有几种解决方法.您可以使用有界队列,如果达到其容量,它将阻塞.您可以在启动时创建x缓冲区,并将它们存储在接收线程从中弹出的另一个生产者-消费者池队列"(而不是malloc)中-然后处理池线程可以将已用" *缓冲区推回到池队列以供重用.如果池用完,则接收线程将在池上阻塞,直到返回* buffers.

If you find that the datagrams can arrive so rapidly that the processing cannot keep up, memory use will grow unchecked as more and more *buffers pile up in the queue. There are a couple ways round that. You can use a bounded queue that blocks if its capacity is reached. You could create x buffers at startup and store them on another producer-consumer 'pool queue' that the receive thread pops from, (instead of the malloc) - the processing pool threads can then push the 'used' *buffers back on to the pool queue for re-use. If the pool runs out, the receive thread will block on the pool until *buffers are returned.

我更喜欢池缓冲方法,因为它限制了整个系统的内存使用,避免了连续的malloc/free及其碎片问题等,避免了更复杂的有界队列,更易于调整,(池级别很容易可以在运行时进行更改),并且更易于监视/调试-我通常使用计时器每秒将池级别(即队列计数)转储到显示器上.

I prefer the pooled-buffer approach since it caps memory-use across the whole system, avoids continual malloc/free with its fragmentation issues etc, avoids the more complex bounded queues, is easier to tweak, (the pool level is easy to change at runtime), and is easier to monitor/debug - I usually dump the pool level, (ie. queue count), to the display once a second with a timer.

在任何一种情况下,数据报都可能丢失,但是,如果系统过载,则数据定期到达的速度快于可能被处理的速度,无论如何设计,情况都是如此.

In either case, datagrams may be lost but, if your system is overloaded such that data regularly arrives faster than it can possibly be processed, that's going to be the case anyway no matter how you design it.

一个套接字就可以了,那为什么使事情变得复杂呢? :)

One socket is fine, so why complicate matters? :)

这篇关于多线程udp服务器的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆