unit testing: theory vs practice

unit testing: theory vs practice

I am extensively using unit testing for more than 10 years. However, when
I am reading recent books and stack-overflow question on best unit test
practices there is a striking difference with unit tests I routinely do.
I am working on large systems consisting of many cooperating processes and
my projects usually act as intermediate servers in the chain - I have
several client processes on the left and several back-end servers on the
right. My unit tests environments consist of mock clients, back-ends and
IPCs, with the SUT sitting in between. My test cases consist of starting
transactions passing it all the way around with responses or failure
indications received back.
My primary targets are failures, overloads and corner cases: rx blocked,
packets lost, one or another pieces disconnects, timing issues. Once I
have basic sets of tests running I will run gcov and will add cases to get
decent overall test coverage.
Please, help me reconcile it with general advise of writing a lot of small
test cases each testing one code path in one method - while I see the use
of it, it seems that it will be prohibitively expensive to get to the real
needs of testing system-wide corner cases that are close to impossible to
create in during testing of the real systems.