I have read that the overhead is low. What does it really mean when compared to HTTP? Does it not use the ip address of the server to which a client tries to connect to? If not, how does a client connect to a server?
Low overhead means that for a given size of messages there is very little extra information sent. It has nothing to do with broker discovery.
E.g. for a HTTP message there us a relatively large amount of HTTP Headers sent before any of the message is transmitted.
The client will connect to the broker via it's IP address. This can either be known in advance, looked up from a host name via DNS or looked up via a TXT record in the DNS for a given domain. You can see examples of broker discovery on the mqtt.org site here
Related
I am using eclipse paho java client to connect to mqtt broker.
Have written a subscriber client implementing MqttCallbackExtended.
I am getting connectionLost() callback.
But how do I get to know that which broker lost the connection.
I have specified multiple uri's via setServerURIs() api of MqttConnectOptions.
If you have specified multiple brokers, they all should be part of the same cluster offering the same topic space.
This means you shouldn't need to care from the client side which broker you were connected to as the client will just move to the next in the list when it tries to reconnect.
But if you really need to know, then you can always log the URI when the connection is created using the information from the connectionComplete() callback on the MqttCallbackExtended class
In C++ (I didn't include code because this is more of a protocol understanding matter) I am creating a SOCKS5 server and had a few questions because the client terminates the connection after I send it the approved message. In the RFC it says BND.ADDR and BND.PORT are used for: RFC 1928
o BND.ADDR server bound address
o BND.PORT server bound
port in network octet order`
In the reply to a CONNECT, BND.PORT contains the port number that the
server assigned to connect to the target host, while BND.ADDR
contains the associated IP address.
Here are my questions,
What is BND.PORT and what should I specify for it?.
What does it mean by "server assigned to connect to the target host" Is target host the "Client"?
I've read the RFC front to back like 5 times and I have yet to understand it, can someone go into more detail about the BND.PORT and what it means?
I was sniffing around in Wireshark and I found that BND.PORT was different for each request made. (I am not sure what port to enter because everything I tried resulted in Proxifer (The socks client) says "The server gave an unexpected replay - Connection terminated"
Wireshark connection hex-dump from an actual SOCKS5 server (not mine):
Just to make sure we're on the same page... This is the relationship between client, server and host. Notice that the client and host can't talk to each other directly.
CLIENT <-> SERVER <-> HOST
What does it mean by "server assigned to connect to the target host" Is target host the "Client"?
No. The "host" is the device the client is trying to connect to via the SOCKS5 server. The "client" is on the other side of the SOCKS5 server, furthest away from the host.
What is BND.PORT and what should I specify for it?.
BND.PORT is the source port of packets leaving the SOCKS5 server, bound for a host. You have no control over what port the server chooses. Think about it. Where does a host see packets coming from? It certainly isn't the client. From the perspective of the host, packets are all coming from the server, it doesn't know about the client. Additionally the BND.ADDR is the IP of the server.
What I've said is true under the condition that CONNECT is being used. I have no experience with BIND or UDP ASSOCIATE yet.
Sorry, links to Indy documentation are currently not working for me. I don't know if the sites are down or whatever but they're not loading in my browser at the moment.
I have a TIdCmdTcpServer in one "server" application, and a TIdCmdTcpClient in another "client" application. I know how to get the IP address of the Client once it has connected. What I don't know is how to distinguish between 2 clients that connect from the same ip address. Can anyone help?
This isn't really an Indy question, more a general networking one.
Different clients at the same address must use distinct ports. And here I mean the port at the client end of the connection. So you distinguish between different clients at the same address by dint of them using different ports.
DO NOT use TIdCmdTCPClient with TIdCmdTCPServer. They are not meant to be used together, and it is very easy to deadlock your communications with them, as they both use internal reading threads that expect the other peer to send data. Use TIdTCPClient with TIdCmdTCPServer or TIdCmdTCPClient with TIdTCPServer.
With that said, you could use the client's remote IP/Port to differentiate, but it is generally better to make your own identifier instead, such as requiring clients to log in with a username, that you can then track as needed.
I have built several applications in delphi using the indy components suite(version 10.5.2 i think) and they all are working. I have just finished setting up the POP3server and it works locally. I can see mail sent locally on there. I have been using "localhost" as my hostname. However, i want to graduate to a higher level of function. I want to be able to receive email from the internet such from msn, gmail, yahoo ... The problem is I don't know how to do this. What address should I be using inorder to do this? So far "myhouse#localhost" has been working but only internally; can't seem to get external mail in there. Is it possible to receive mail like this? Thanks.
You need to register a domain, and then setup its DNS records (in particular, its MX records) to point to your server machine. That way, when an email is destined for any "#yourdomain" address by any sending service, it will be routed to your server machine (which needs to run an SMTP server to receive emails - POP3 is for downloading emails from your mailbox, not for putting emails into it). If your server does not have a static IP, then you need to use a service like DynDNS to mange the DNS records for you so they can account for your dynamic IP whenever it changes.
"The Internet" doesn't use POP3 to send and receive email, it uses SMTP. Here's how email "flows" from the sending computer to the receiving computer:
Server needs to send email to address: myhome#localhost. The first thing it does is isolate the server name, that's the part after "#". Next it uses DNS to lookup the SERVER IP for the computer that's supposed to receive email for the given domain. DNS contains a special record for this purpose, it's called the "MX" record. You can use command line tools like dig on Linux or nslookup on Windows to find this address, or you can use an online tool like the one found at http://www.mxtoolbox.com/ (google found this site, I assume there are many others!).
If you try to locate the MX record for your "localhost" domain you'll obviously discover it's not possible, because it's not a fully-qualified name. You first need to get yourself an domain name, so you can register a MX record!
Things you need in order to RECEIVE email
Need an "real" IP address. Servers outside your local network need to contact your server, and they obviously need a way to do it. Make sure no routers along the way block SMTP ports.
You need to register an domain name, add a MX record and point it to your "real" IP address.
Need to run SMTP server software on your box. You can use Indy components to write one.
Things you need in order to SEND email
Theoretically sending email with SMTP is the easy part. You just contact the responsible server using SMTP and send email, that's the way the protocol works: any computer in the world may send email to any SMTP server.
Practically sending email is the most difficult thing you'd have to do, mostly because foreign SMTP servers don't trust you (ever heard of SPAM?). Here are some of the things you might need to do so foreign SMTP servers accept email from you. There's no definitive list because the protocol itself doesn't include a clear authentication mechanism, so every big SMTP server out there uses it's own heuristics to decide rather to accept email from you or not. You'll find yahoo especially fun!
You need to have REVERSE DNS for the IP you're using to send email.
You need to send from one of the SMTP servers listed in DNS as your MX servers.
Your DNS records need to have long TTL (this rules out Dynamic DNS services)
Many other things...
What people usually do?
eMail is hard, there's a surprisingly small number of full SMTP servers available for your own server: Exchange, Notes, Postfix, QMail, Sendmail. They're all notoriously difficult to configure. Most people would use hosted mail services, some people would use the SMTP services provided by the ISP, and very few would install one of the mentioned services.
If you really want to write your own SMTP server go ahead, but you might want to install one of the ready-made ones before, to get a bit of eMail and DNS experience. The Linux ones are cheap to install and may also help with development (you don't want to send too much bad email to your free yahoo address, you might get blacklisted!)
POP3 is a protocol to read email from a mailbox. The TidPOP3Server component implements a POP3 server (and AFAIK it has no host property to set...), while TidPOP3 implements a POP3 client. To read mail from GMail or any POP3 server you need a TidPOP3 component. The hostname to set is the DNS name the service instructs you to use (i.e. pop3.mydomain.com).
If you have two browser windows open and you use each to navigate to a different website, then how does the software know which HTTP response belongs to which browser instance?
Update
It seems that the distinction is made by the inbound TCP port numbers. But what about network messages that don't involve TCP/UDP? For example, if you open two terminal applications and use both send a ping message to the same remote server, how does the reply find its way to its terminal instance?
Typically, each browser instance creates its own socket to communicate with the server. Though the outbound port of all the sockets is the same (usually TCP 80 or 443), their inbound ports are different. Thus, there are no conflicts when the server responds to the requests, since the responses are sent to different inbound ports.
Tools like ping use ICMP packets, which provide their own way to uniquely identify the calling application (a unique identifier and a sequence number).
They're usually associated with different TCP connections, which between them have used different ports on the client end. This means that the TCP stack at the client end knows the different and passes them via the sockets API the client used in an easily distinguishable way. (Typically different file descriptors)
The exception to this is pipelining where multiple http request can be sent over one connection, as an optimisation. Requests sent like this are received in the order they were sent however, making it trivial to match them to the requests.