1

I'm breaking my mind trying to understand how make a client/server write by myself accept multiple socket connections.

The connection is a datagram (UDP), for now was implemented based on getaddrinfo(3) man page works nice, but each client needs to wait the process of early connections be processed.

I've heard about select, but in its man page says:

select() can be used to solve many problems in a portable and efficient way that naive programmers try to solve in a more complicated manner using threads, forking, IPCs, signals, memory sharing, and so on.

and more:

The Linux-specific epoll(7) API provides an interface that is more efficient than select(2) and poll(2) when monitoring large numbers of file descriptors.

So, it is? epoll is simply better than select? Or it depends? If it depends, on what?

epoll man pages has a partial sample, so I'm trying to understand it.

At now, (on server) I think, I need a thread to listen in a thread and write in another. But how to control the completion of a partial message? If two clients send a partial message interleaved, how to identify? By the sockaddr? if it's the only need, I can manage it without a pool, so why use a epoll?

Can anyone try to explain to me, how to make, or where to learn about a multi-connection client-server UDP app?

Michael Petrotta
  • 59,888
  • 27
  • 145
  • 179
ton
  • 3,827
  • 1
  • 42
  • 40
  • 1. Yes, `epoll` is better than `select`. 2. Read the book [Unix Network Programming](http://www.unpbook.com/) – Yu Hao Jul 22 '13 at 03:00
  • I'll read it, thanks for response... If you promote your comment to a response, I'll vote it. – ton Jul 22 '13 at 03:12
  • 1
    There is no such thing as 'accept[ing] multiple UDP connections'. There is only reading UDP datagrams from one or more remote sources. – user207421 Jul 22 '13 at 03:57

1 Answers1

6

I think there is a misunderstanding here about UDP. UDP is not a connection oriented protocol which means there is no permanent connection like TCP. UDP just bind to an address/port and waits for packets from everyone. At the server there is only one socket listening per address/port number. When a packet is received you may find out who is the sender by the packet's source IP, you can reply to the sender thru this IP.

As I see it, there is no need for poll() o select() you bind to an address/port and asynchronously receive packets. That is, when a packet is received you get a signal/message alerting your asynchronous function. This function should be reentrant, it means that in the middle of a reception another signal could be received and care must be taken when accessing/modifying global stuff (variables/objects). When dealing with an incoming packet it should be processed as soon as possible or, in case the process takes too long, you better keep the packet in a packet spool and process them in another [less priority] thread.

For UDP packet size read this question.

For UDP fragmentation read this

For UDP packet header read this

Community
  • 1
  • 1
ja_mesa
  • 1,971
  • 1
  • 11
  • 7