Actually, even with contemporary communication protocols today, latency is not really an issue as long as the link is reasonably reliable. This is a delay-tolerant network. Note that in the real world, with long-range communications you are going to have to add a good chunk of forward error correction so that the majority of errors can be repaired without requiring re-requests and retransmission of the data.
There was even an Internet Draft published some years ago that discussed how an "interplanetary Internet" could function. I would have to go and dig it out, which I am not terribly inclined to do at the moment, but the gist was that yes, it would work quite well with only minor alterations to the low-level protocols. IP would be fine. UDP, ICMP and friends wouldn't fare too poorly. TCP wouldn't do great in a high-latency environment with its roundtrips, but that wouldn't necessarily be a showstopper if the latency can be kept to a reasonable level (think perhaps minutes; the limiting factor would probably be a combination of how long you're willing to wait, and your ability to track both endpoints in space).
The real killer was when you started applying the high latency to higher-level protocols, and contemporary implementations of those. Something like plain HTTP, with a single request followed by its associated response, wouldn't be too bad. A protocol designed to be used interactively, like FTP or SMTP, however would not work very well as currently designed because the latency would be multiplied by the number of roundtrips. DNS would definitely have problems because it is relatively latency-sensitive. This is not an insurmountable problem, but it is something some of our current protocols are not well equipped to handle being designed for an environment where a latency of one second is extremely high.
Since this I-D was written in the context of our real world, with our real world physics, they also had to deal with the fact that not all nodes would be visible (radio link wise) from all other nodes, or even any given nearby node, at all times. So how do you solve all this? Well, it turns out an easy solution is to design a network using
store and forward
Store-and-forward is a very old technique for building computer networks. Technically at some level all switched or routed networks are store-and-forward, but the forwarding is done so quickly we don't normally think of them as such. In a real store-and-forward network, you may hold on to packets for hours or days until they can be transmitted to the next node, bringing them closer to the destination endpoint. For two examples of store-and-forward networks, consider Usenet and FidoNet. Internet e-mail also used to work in the same manner.
Store-and-forward networks do not provide real-time communication services, but lend themselves very well to batch- and message-oriented communications. E-mail (both personal as well as in the form of discussions) works well in such a network. Web browsing as we know it wouldn't work as well, simply because of the delays involved, but there is nothing in principle that prevents it from working. Delivering batch requests to be processed and the results later returned works fine. And so on.
So you'd have to design your communications systems to account for this latency. That means no video screen showing a faraway higher-ranking commander for a two-way chat. Depending on how much bandwidth you have and the needs of the story, you could either have audiovisual, just audio, or just text, with or without separate channels for data for computers to process. Just text is where it would most likely start out, since that requires by far the least bandwidth (and as an added bonus is possible to skim through and get the general gist of, unlike a video message which must be played back at normal speed). It also means communications more like e-mail or perhaps even postal letter, or something like what we're doing right here on Stack Exchange with the question and answers format, and much less like a telephone conversation.
The actual data could then be carried by specialized vessels, or piggybacked on ships already enroute to the destination area, or carried through a quickspace network like someone mentioned and carried into normal space near the endpoint. But the above allows you to deal with the latency introduced by the fact that the message must be carried somehow.
