sockets

Started by
7 comments, last by hplus0603 18 years, 1 month ago
Hello World! I've got a few questions for you. 1. When should I use blocking / non-blocking sockets? 2. Should I establish a connection with a non-blocking udp-socket? 3. Are datagrams expensive to send? What options do I have? I'm truly greatful for any answers!
Advertisement
Quote:Original post by wolfram
1. When should I use blocking


Never... it shouldn't even be possible, but since you can treat a socket like a file descriptor on most platforms it's the default configuration.

Quote:
2. Should I establish a connection with a non-blocking udp-socket?


You can't establish a connection with UDP. UDP is connectionless.

Quote:
3. Are datagrams expensive to send?


No.

Quote:
You could use TCP.


What options do I have?

Quote:
I'm truly greatful for any answers!


You'e welcome.
Quote:Original post by wolfram
1. When should I use blocking / non-blocking sockets?

When you need blocking/non-blocking.
Blocking sockets are conceptually separate from each others. Each socket usually has a thread assigned, which sleeps when nothing is happening on the socket.
Nonblocking allows one thread to check on all your sockets, read incoming data or start sending, without, well, blocking.

The former is probably easier if you need something that only requires a smallish number of connections, and if the connections can be handled on its own, without too much coordination with other sockets or some global program state.
You will get horrible performance if you try to juggle too many connections with blocking sockets though, due to the excessive number of threads.

Quote:
2. Should I establish a connection with a non-blocking udp-socket?

You can't. UDP is a connection-less protocol.
Quote:
3. Are datagrams expensive to send? What options do I have?

Datagrams are very lightweight. The point in UDP is to make the simplest, most minimalistic protocol possible (without rendering it completely useless). But even so, sending/receiving data still takes ages (from a CPU's point of view). Not because UDP or datagrams are inefficient, but because even gigabit lan is slooooooooow compared to a CPU.
Quote:Original post by wolfram
1. When should I use blocking / non-blocking sockets?
2. Should I establish a connection with a non-blocking udp-socket?
3. Are datagrams expensive to send? What options do I have?


  1. Usually, you'd use blocking sockets if you want your code to only handle network events, e.g. a SMTP server that does nothing except handle clients. The other alternative would be if you have your network code in a seperate thread and you don't mind about it waiting for most of the time. Otherwise, you'd use non-blocking sockets

  2. As the AP said, you can't "establish a connection" with UDP sockets. Your UDP socket could be listening on the server though, in either blocking mode (In accept()) or non-blocking mode (Checking with select())

  3. Define "expensive". A UDP datagram is one packet, and will be sent as one unit across the network. TCP may split a message into several packets, or it may combine several messages into one larger packet. There's a little more overhead from using TCP (Due to things like guaranteed in-order delivery), but not much of a difference


What are you trying to do exactly? A lot of the answers to your questions depend on what you're trying to do in the first place (If you're writing a single threaded, multiplyer FPS, you wouldn't use blocking sockets and TCP/IP for instance).

EDIT: Too late [smile]
I use blocking sockets almost exclusively with UDP on a single thread. I'm not exactly sure why everyone here is acting like if you go with a blocking model that you have to use a bazillion threads, or a small connection count.

select() and poll() are written so that you can manage your blocking sockets, without spending time waiting for data in a blocked state, you are returned a list of sockets with data waiting. If you are using TCP, your connect() calls will block unless you thread them, so non-blocking is a better model for TCP. But since UDP is connectionless, you don't have to worry about blocking during connects.. use poll() and select() and you should be fine.

Quote:Original post by Anonymous Poster
select() and poll() are written so that you can manage your blocking sockets, without spending time waiting for data in a blocked state, you are returned a list of sockets with data waiting. If you are using TCP, your connect() calls will block unless you thread them, so non-blocking is a better model for TCP. But since UDP is connectionless, you don't have to worry about blocking during connects.. use poll() and select() and you should be fine.


That would depend on your implementation platform, actually. Select() is not really desireable on Winsock, for example.

For UDP, you can just check the socket in non-blocking mode rather than calling select.

--Dave
Quote:Original post by Evil Steve
Define "expensive". A UDP datagram is one packet, and will be sent as one unit across the network. TCP may split a message into several packets, or it may combine several messages into one larger packet.


Actually, UDP packets can be fragmented. It is just that if any fragment fails to arrive, the whole packet is dropped rather than causing a retransmit of anything.

--Dave


Thank you all for your answers!

There is one more thing, thought, that I dont understand.
Accept() is used for establishing a connection, right?
What does connect() do? Is is something that I should call on a non-blocking udp-sockets?
Quote:Accept() is used for establishing a connection, right?
What does connect() do? Is is something that I should call on a non-blocking udp-sockets?


accept() is the server-side response to a client connect() for a stream-based socket.

For a UDP socket, if you call connect() on it, it means that you can't send to any other address than what you connect()-ed. It also means that you can use send() instead of sendto() on that socket, because the target address is bound. However, the other end won't know that you've called connect().
enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement