irrNetLite is based on enet, which is based on UDP.
Now Enet does technically provide a reliable layer similar
to TCP over UDP but packets may still be dropped. They are also not guaranteed to be in order.
This was a conscious decision of course, as a lot (But not all) of game network content would benefit from this approach, since TCP usually provides too much overhead for things like sending player positions, etc (Things where the most recent packet is needed, and the older packets can be discarded). With irrNetLite, sendOutPacket() should provide reliable delivery of packets (But not in-order delivery). When you don't care about reliability and want to save on bandwidth you can use sendOutPacketUnreliable() which doesn't bother resending packets if their not received.
Now to answer your questions:
1) Is it possible for packets to be received in an order other than they are sent? My host sends a game description out to clients whenever they connect, and I've got a problem where the client will receive packets pertaining to a game they haven't received details about yet. So it would seem that the packets sent using the OnConnect callback are being received after packets sent at other times. Is this possible? I would have thought that OnConnect() would be called by the host before a new user started receiving packets, or is this not the case?
Yes, it is possible. What I recommend you do is combine these 2 packets into a single packet. Then you would have all that information in the intended order. Is there a reason that is not practical? Enet can take any packet size and split it up into smaller packets then join it again, so packet size is not usually an issue unless it is so big that it would eat performance (Anything under 10kb should be fine).
2) Is it foolish to have a system that relies integrally on every packet being delivered successfully, or should I take into account the possible that data may be lost?
Not foolish, this is what TCP is for. Like I said earlier you may be better off combine sequential data into the same packet, then you are guaranteed to receive it in the same order. If you are sending packets so close together that the later one would arrive before the other then I guess you would have no problem with just combining them into the same packet.
Waaait a second... the Enet website says this:
ENet provides sequencing for all packets by assigning to each sent packet a sequence number that is incremented as packets are sent. ENet guarentees that no packet with a higher sequence number will be delivered before a packet with a lower sequence number, thus ensuring packets are delivered exactly in the order they are sent.
For unreliable packets, ENet will simply discard the lower sequence number packet if a packet with a higher sequence number has already been delivered. This allows the packets to be dispatched immediately as they arrive, and reduce latency of unreliable packets to an absolute minimum. For reliable packets, if a higher sequence number packet arrives, but the preceding packets in the sequence have not yet arrived, ENet will stall delivery of the higher sequence number packets until its predecessors have arrived.
So apparently Enet does guarantee sequenced delivery. We may be running into this issue: http://lists.cubik.org/pipermail/enet-discuss/2007-October/000746.html
Before I make the next release I'll run some tests and see if there's anything weird going on. This'll have to wait as I have exams this coming week and the next.