Vamos por parte:
* Para que un webform de un aplicativo web pueda comunicarse con una base de datos en otro servidor solamente se requiere: 1) Que el servidor donde está la base se pueda "ver" desde la PC origen; y 2) Que el StringConnection tenga los parámetros correctos.
La primera de las dos cosas no tiene vinculación con la base, sino con la topología de la red y las políticas de seguridad, por lo que no son ámbito que puedes controlar. Eso se configura en los niveles 1, 2 y 3 del modelo OSI.
La segunda de las cosas, sí es control del programa, pero dependerá de la forma decidida de conexión. La implementación de la apertura de enlace según el protocolo elegido está programado en los NameSpaces que uses. Sólo debes saber usarlo.
Ocasionalmente, algunos de ellos requieren cierto nivel de ajuste externo, como es el caso del ODBC, pero los .Net no. Ya están integrados al CLR.
Ahora bien, cando se trata de aplicaciones en la web con servidores en la web, la cosa es mucho más simple: solamente necesitas sus IP, ya que por definición el protocolo es TCP/IP.
Yendo a tu pregunta
Cita: ya que de todas formas la información se debe encapsular de acuerdo a otro protocolo para que sea compatible con lo enviado por el webform y la base de datos.
Estás confundiendo un detalle: el "empaquetamiento" (supongo que te refieres a los
datagramas del TCP) no es tarea del programa, que esta en la capa 7 del modelo, sino de todas las capas inferiores (especialmente las 4, 5 y 6), ya que la fragmentación de los datos para transporte se da allí.
De hecho, cada vez que envías un e-mail con un adjunto, o descargas o subes un archivo con un webbrowser, estás haciendo la misma tarea, ya que sabrás que el webbrowser es un aplicativo y está en la capa 7... no en la 3 (la capa de red). Quien se ocupa de esa segmentación, entonces, sigue siendo invisible: la capa 4 o de transporte.
La única forma en que la programación de un aplicativo (de escritorio o web) puede optimizar los recursos de la capa de transporte está en la reducción de los datos a transferir, ya que al reducir la cantidad de datos enviados o recibidos al mínimo necesario, te aseguras que la cantidad de datagramas transportados sea lo menos posible.