Hi, I have a bunch of questions and I thought I'd just make one post instead of many small ones. 1) What kind of hints should we use for sockets? Does supporting IPv4/6 matter? In the real world, is there such thing as a device that only uses IPv4 or only IPv6? 2) getaddrinfo() gives multiple addresses. Can we just use the first in the list? Are they all valid? 3) The marking rubric asks us to support multiple concurrent queries. Does this mean clients are allowed to wait in a queue, or does it mean multithreading, or an event system? Is there a way to setup events with and without timers in C? 4) Within localhost, there's no transmission errors. Do we need error checking/acks/etc? What kind of error checking is needed? Does TCP need error checking/acks if it's "reliable" (as mentioned in the Getting Started page). 5) Sending X bytes using send()/sendto() apparently doesn't always send X bytes, it might send less. Why? What factors does it depend on (message size, external network activity)? What does the receiver see if I send 1 message using 2+ send calls? Thanks

Hello, ANONYMOUS wrote: Not sure what you mean by 'hints' here. For the project, you may assume that all addresses in use are IPv4, as not all (limited) devices support IPv6 and not all systems choose to enable/support it by default. They should all be valid, so just use the first one. If you were writing a client anticipating that a server would be heavily loaded, you might choose one of them, randomly (but no guarantees that it would have a noticeable effect). Multiple people (using a web-browser) may contact the same station-server with a query. Some queries may be resolved immediately, others require network I/O to query other station-servers. There should be no need to support multithreading for this - you'd use multithreading if you had something else to do/execute while waiting for I/O to complete, but we don't. The arrival of network queries, from browsers and other stations-servers, are the events (you don't need a 'system' to manage these). You may assume that all communication using TCP is reliable - it's its job to provide the reliability - though you should detect/handle errors that *it* reports. Write()s can fail, or only be 'partially' successful; your project shouldn't try to anticipate what way/did go wrong, but should handle things if problems are reported/indicated by the APIs. ___ You've asked good questions, and I'm happy to clarify things. But things to be resolved/decided should be discussed with your team members.