2

I'm trying to build a section of my app where two users can message each other. I've read about TCP and UDP and it seems like TCP is more suited due to ordered packet delivery. However, TCP requires a connection between the two users at all times for data to be sent but in my app one user may send another user a message even when the user receiving the message isn't on the application.

How do I get round this problem? I would ideally like to make the application P2P so I don't need a dedicated server but is the reality that I do need a dedicated server ran using TCP that can then delivers the messages when the user connects?

Or, alternatively I'm using mysql as the database to store the chat history so can I just load the latest messages off that when the users logs in?

Improve this question
9
  • 1
    How does one decide between TCP and UDP?
    – Robert Harvey
    Mar 14, 2020 at 12:32
  • 3
    Message persistence is a different problem. Neither TCP or UDP have a solution for that. If you want sent messages to arrive when the client later connects, you need some sort of persistent message store.
    – Robert Harvey
    Mar 14, 2020 at 12:33
  • Do you have a recommendation of a persistant message store?
    – Callum
    Mar 14, 2020 at 13:02
  • 1
    If you dont use some kind of server, the users need to open nat/firewalls ports for your chat to be able to send message into the client. You can use something like the sip protocol to solve this. (in many cases but not all) but still you need some way for client a to know where client b is. I would build something like this where the client connects to server with secure websocket. This is over tcp and https. In most cases https and websocket will work without any firewall/nat configurarion.
    – Mr Zach
    Mar 15, 2020 at 9:48
  • 1
    I would highly recommend integrating with an existing chat service (like Slack, Jabber, etc.) rather than re-inventing the wheel completely.
    – Berin Loritsch
    Mar 16, 2020 at 16:46

2 Answers 2

Reset to default
1

Please review carefully the suggestion made by Robert Harvey, above.

TCP requires you to "open a socket" and then guarantees two-way ordered conversations. If you send three packets, they will all arrive and they will arrive in the sequence that you sent them. You don't know and you don't care how many sockets the server might be talking to at any one time. Your "request to connect" may be delayed or refused.

UDP puts a message into a bottle and tosses it into the sea. It might never arrive. It might arrive before or after some other bottle. You will never know if it arrived. You don't even know if the intended recipient is alive at all, much less pulling bottles out of the water. The only way you'll know if your message was heard is if another bottle washes up on your shoreline, and you manage to grab it before it sinks.

Improve this answer
1

I would highly recommend integrating your application to an existing chat solution. Whether you use Slack, Jabber, or any other robust chat solution you no longer have to worry about the persistence problem and you don't have to maintain a custom solution. I realize that Chat doesn't feel complicated, but the bottom line is that there are more things to consider than you think.

Your stated requirement:

I do need a dedicated server ran ... that can then delivers the messages when the user connects

That requires a piece of persistent architecture that exists when the application is not currently running. Your potential solutions are:

  • Integrate with an existing chat solution (does not restrict you to your application, and can easily expand to new requirements you have)
  • Persist using your database (I maintain an application with a poor-man's custom chat feature that does exactly that)
  • Create a custom server to administrate and deliver chat messages

I would also look very hard at the reasons you are wanting to add Chat to your application. The app I am maintaining with a custom poor-man's chat was created because a chat service didn't exist on that particular private network. Rather than getting a proper chat server approved (and there are many), the original developers implemented their own. In the context of what that application does, it is the most superfluous feature that should have been a completely separate service.

You may have very good reasons, and chat may be a more integral part of your application. However, certain chat applications like Slack have an API that allows a level of integration that you wouldn't be able to accomplish on your own. Take a good hard look at the decision to build another version of a chat server.

Improve this answer
3
  • I'm definitely open to piggybacking on whatever's out there, however I've searched for information about Jabber but can't find much at all about it (tutorial docs/videos etc). Do you have any recommendations on tutorials about jabber, or other public XMPP services?
    – Callum
    Mar 16, 2020 at 19:06
  • This might be a good start for XMPP compliant servers: xmpp.org/software/libraries.html . That will allow you to send messages to the server once you've configured your client. You'll need to connect to a server xmpp.org/software/servers.html that you install someplace. If you have access to an XMPP compliant server already deployed, then you just need the client libraries.
    – Berin Loritsch
    Mar 16, 2020 at 20:29
  • So am I right in thinking that I need to use something like sleekxmpp or aioxmpp to pass the messages to a server such as IoT Broker or ejabberd, which I need to install on my computer? As the number of users messaging increase won't I need a better server than my computer, is it possible to use a cloud server and how would this work with IoT Broker or ejabberd.....or have I got this bit wrong?
    – Callum
    Mar 26, 2020 at 19:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.