in reply to nonblocking UDP, "Hello World" level

Can I learn some more about your application, please? In return, I'll try to come up with some appropriate code ;-).

I've just deleted two potential posts trying to second-guess what you want, so I thought I'd just ask instead. Do you want to use UDP because you have very low latency requirements? Is it because you think it will be simpler to start with that and then move to TCP? Will the chat be application-to-application or person-to-person?

Note that you don't necessarily need a threaded or forked application to handle multiple clients for UDP or TCP.

Some background info, sorry if you know it all already.

UDP: each packet sent is standalone. There is no concept of connection. Packets can be dropped and also delivered out of order. If your server side doesn't need to do anything else, it can sit in a loop reading packets from the socket and responding to them, without any nonblocking, selecting, forking or threading.

TCP: a connection is made to a server socket which is listening on a specific port. The server accept()'s the new connection, which creates a socket for that two-way connection. Data read and written is transmitted reliably and in-order. The server needs to manage multiple sockets: the listening socket and all current connections. This can be done with threading/forking or using select (or it's OO wrapper IO::Select), without any need for non-blocking (if the server is doing nothing else).

Replies are listed 'Best First'.
Re^2: nonblocking UDP, "Hello World" level
by Bruce32903 (Scribe) on Dec 06, 2006 at 15:06 UTC
    I am part of a team working on something that is not a "code project". I am actually asking these questions with two goals in mind.

    1) One of my responsibilities is to have small ASAP microcontroller boards with sensors and status lines communicating back to an admin app over ethernet. I don't have final specs yet, but I think that UDP is a requirement placed upon me (thus, no TCP/IP). This will probably be binary data and thus "line operations" that sense "end of line" are probably not an option. That is probably the limit of what I can say about goal #1.

    2) The other goal is to be able to pump and verify many channels of ethernet traffic during testing. I am probably free to use UDP or TCP/IP, and I probably am free to use binary data or ASCII data terminated by CR, LF. I do need to be very confident that I am in control of what data is being sent through each RJ-45.

    The chat application at a "Hello World" level is just to get me started. Developing the code to deal with empty buffers, full buffers, fragmented packets, lost packets, etc should be quite a task by itself. I would like to do as much work as possible in an Intel Architecture to Intel Architecture environment before I put "under development" hardware and "under development" software at the other end of the wire.

    Thank you,
    Bruce