<p>I'm working on a web service at the moment and there is the potential that the returned results could be quite large ( > 5mb). </p>

<p>It's perfectly valid for this set of data to be this large and the web service can be called either sync or async, but I'm wondering what people's thoughts are on the following:</p>

<ol>
<li><p>If the connection is lost, the
entire resultset will have to be
regenerated and sent again. Is there
any way I can do any sort of
"resume" if the connection is lost
or reset?</p></li>
<li><p>Is sending a result set this large even appropriate? Would it be better to implement some sort of "paging" where the resultset is generated and stored on the server and the client can then download chunks of the resultset in smaller amounts and re-assemble the set at their end?</p></li>
</ol>

There's no hard law against 5 Mb as a result set size. Over 400 Mb can be
hard to send
.
You'll automatically get async handlers (since you're using .net)
implement some sort of "paging" where
  the resultset is generated and stored
  on the server and the client can then
  download chunks of the resultset in
  smaller amounts and re-assemble the
  set at their end
That's already happening for you -- it's called tcp/ip ;-) Re-implementing that could be overkill.
Similarly --
entire resultset will have to be
  regenerated and sent again
If it's MS-SQL, for example that is generating most of the resultset -- then re-generating it will take advantage of some implicit cacheing in SQL Server and the subsequent generations will be quicker.
To some extent you can get away with not worrying about these problems, until they surface as 'real' problems -- because the platform(s) you're using take care of a lot of the performance bottlenecks for you.