Live data from Hacker News

Show HN: TCP/UDP over sound

github.com

1–10 of 81 posts

Re: Show HN: TCP/UDP over sound

#4
post #3

Clever, an audio soft-modem. Was there a reason to not implement this as an actual modem with a frequency band assigned to either channel and then to run SLIP or PPP over it?

Difficulty level, probably. I'd love to see both and also one that can survive over GSM audio (is that even possible?)

Re: Show HN: TCP/UDP over sound

#5
post #3

Clever, an audio soft-modem. Was there a reason to not implement this as an actual modem with a frequency band assigned to either channel and then to run SLIP or PPP over it?

Difficulty level, probably. I'd love to see both and also one that can survive over GSM audio (is that even possible?)

GSM is definitely possible, but you'd struggle to get more than 2kbit/second (and that'd be over a good connection). You'd probably need FEC to pull it off.

Re: Show HN: TCP/UDP over sound

#6
post #3

Clever, an audio soft-modem. Was there a reason to not implement this as an actual modem with a frequency band assigned to either channel and then to run SLIP or PPP over it?

The goal of this library is to provide the familiar sockets interface over a non-traditional eth, in this case sound.

Can you expand on your question? I think I understand what you're saying but I don't quite see what it would accomplish.

And this is an "actual" modem, whatever that means. If you mean an IETF/RFC modem spec, there are many reasons. Those specs are focused on narrowband POTS limitations, which we don't face over a less-restricted channel. Implementing those features might be interesting from a vintage perspective but would require substantial work to achieve compatibility for relatively little gain.

Re: Show HN: TCP/UDP over sound

#7
post #3

Clever, an audio soft-modem. Was there a reason to not implement this as an actual modem with a frequency band assigned to either channel and then to run SLIP or PPP over it?

The goal of this library is to provide the familiar sockets interface over a non-traditional eth, in this case sound. Can you expand on your question? I think I understand what you're saying but I don't quite see what it would accomplish. And this is an "actual" modem, whatever that means. If you mean an IETF/RFC modem spec, there are many reasons. Those specs are focused on narrowband POTS limitations, which we don'…

If you did it as a traditional modem then one could hook up any old piece of software to the appropriate character devices and you'd be off to the races. Not everything is sockets, and there are simple and relatively easy to use wrappers around a standardized serial character interface to turn such a connection into one supporting all of the regular internet protocols. It seems - but I may be wrong about this - that this solved something at a different layer than what I would have expected.

Re: Show HN: TCP/UDP over sound

#8
post #7

Earlier quoted context omitted.

The goal of this library is to provide the familiar sockets interface over a non-traditional eth, in this case sound. Can you expand on your question? I think I understand what you're saying but I don't quite see what it would accomplish. And this is an "actual" modem, whatever that means. If you mean an IETF/RFC modem spec, there are many reasons. Those specs are focused on narrowband POTS limitations, which we don'…

If you did it as a traditional modem then one could hook up any old piece of software to the appropriate character devices and you'd be off to the races. Not everything is sockets, and there are simple and relatively easy to use wrappers around a standardized serial character interface to turn such a connection into one supporting all of the regular internet protocols. It seems - but I may be wrong about this - that…

Ah, yeah, that makes sense. My plans for this library are mostly focused on using the sockets directly, with the library linked by both peers. I'm really interested in being able to use this as a simple UDP client/server.

Re: Show HN: TCP/UDP over sound

#10
post #7

Earlier quoted context omitted.

If you did it as a traditional modem then one could hook up any old piece of software to the appropriate character devices and you'd be off to the races. Not everything is sockets, and there are simple and relatively easy to use wrappers around a standardized serial character interface to turn such a connection into one supporting all of the regular internet protocols. It seems - but I may be wrong about this - that…

Ah, yeah, that makes sense. My plans for this library are mostly focused on using the sockets directly, with the library linked by both peers. I'm really interested in being able to use this as a simple UDP client/server.

You'd get that just about for free by running SLIP or PPP over your audio modem.
Post reply on HN