Talking to the RPC via UDP? about thrift-swift HOT 5 CLOSED

You should be able to configure the socket protocol here using IPPROTO_UDP / SOCK_DGRAM instead of IPPROTO_TCP / SOCK_STREAM for the server. Although you will likely need to come up with a different Transport to read/write on that protocol.

If you can get this working, feel free to submit a pull request with some options.

from thrift-swift.

@wyland Sure, I'll be implementing the service first to have something to try against.
One concern is that UDP doesn't work that well on iOS devices as the hardware might sleep, I am trying to figure out how to wake it up. Apple docs recommends not to go with low level POSIX code and instead using CFSocket which you guys seem to be doing, I am just trying to wrap my head around how to kickstart the device to start sending the packages. Do you got any experience with UDP on iOS - or more specifically, UDP across cellular connections?

from thrift-swift.

Another note, I am wondering if it were to be a better solution to "outsource" the socket stuff to a third party library like IBM/BlueSocket.

from thrift-swift.

Unfortunately we rely on TCP and don't have any personal experience using UDP. As long as you conform to TTransport, I don't believe you will run into any issues using a third party like BlueSocket as your client to a thrift service.

from thrift-swift.

@wyland I am not saying replacing TCP with UDP, I am asking if the internal implementation regarding socket communication (regardless of TCP/UDP) would be better served and simplified by using a layer on top that tackles all the cruft.

The way I see it, handling all edge cases regarding networking should be "outsourced" to a library which main concern is just that.

The reason is, if I add support for UDP, I don't trust myself to know enough to make it good enough compared to an existing solution that tackles that.

from thrift-swift.