Is it possible to use FTP protocol for an instant messaging software instead of other common protocols?
It is possible to build some kind of IM app with the FTP protocol but it would be painful, slower than others and probably insecure.
You might want to consider
XMPP is the open standard for messaging and presence
https://xmpp.org/
Related
we are replacing websocket instead of ssh-tunnel. May i know how websocket is better than ssh-tunnel?
WebSocket is a protocol designed for 2-way real-time communication between browsers and servers to replace hacky solutions like long polling and XHR streaming.
SSH is a protocol designed for operating network services securely over an insecure network. Usually it's used for remote logins, file transfers, however it can be used for any protocol, however a few modifications need to be made.
The difference between them is, well, WebSocket is designed to be used for the browser and has support there. However, SSH is a more general protocol and can be used for more however it is not supported by browsers directly, but through proxies which bridge WebSocket to SSH.
There is nothing inherently "better" about WebSocket against SSH. It just depends on your use case, if you want to make a remote terminal or something for your sysadmins, use SSH. If you want to use it for, say, a real time chat in the browser, use WebSocket.
I am working on a project which involves real time chat (messaging, including group chats).
I have worked with websockets before, So I started working on this using spring-websockets and I did some reading about what is the best way to implement it. Then I came across STOMP (as a sub-protocol for websockets)and as there is direct support for STOMP in spring it was bit easy to achieve what I was supposed to do.
But my doubt is as far as my understanding STOMP and XMPP are similar protocols(messaging protocols) but I could not find any questions/blogs where the differences are explained and why somebody would prefer one over another?
It will be really helpful if somebody explains how these two protocols differ?
Thank you.
As the successor of Jabber, XMPP is more focused on instant messaging instead of STOMP. XMPP is an extensible protocol and could be used for other purposes, but there are plenty of built-in mechanism and implementations regarding IM. STOMP offers a more general mechanism and "message" here refers a broad meaning.
Let's say you choose STOMP for your project. Then you will probably need to define basic messages for certain scenarios (peer-to-peer, group chat) which are already offered by XMPP.
To compare two protocols;
STOMP message is carried as plain text (as its name indicates) whereas XMPP is structured as XML.
STOMP connections can be established via TCP or WebSockets. XMPP supports TCP or HTTP (WebSocket standard is also propopsed).
In Java world, Spring has the ability to talk STOMP and it's very easy to implement. However, XMPP support can be added by adding 3rd Party APIs (i.e. Smack)
I built a realtime application that, thanks to Socket.IO, can serve a lot of different client types (C#, Java, Browser, ...)! I know that there are a lot of Socket.IO alternatives, but from my understanding, everything is more or less based on WebSockets. (I know that Socket.IO has fallbacks if WebSockets are not working, but that they are more less "inferior workarounds" so to speak...)
My question is: Is there any comparable real-time engine available that is NOT based on WebSockets, but can still serve all those different clients?
You don't say what your endpoints are. If one of the endpoints is a browser with purely the built-in capabilities of the browser and Javascript, then a webSocket is your only way to get a continuous connection from the browser to some other destination.
If a webSocket is not supported (in an older browser), then the other socket.io fallbacks (such as xhr-long-polling) are the next best alternatives. As the browser has limited communication capabilities, if you can't use a webSocket, then an ajax call is your only other generally supported option without requiring plug-ins on each browser (such as Flash or Java or something like that). socket.io already supports the next-best options that are available in a browser - you can't do better than that if you're talking about a standard browser with no custom plug-ins.
If your endpoints don't necessarily include a browser and you can use any language or library you want, then you can use plain TCP sockets and then use whatever protocol you want over a TCP socket.
The WebSocket protocol establishes a bidirectional communication channel between server and client; they kind of speak more naturally with each other. The server can just send something to the client and the other way around. In http it just goes in one direction, there's a request and a response and everything needs to be initiated with a request from the client.
From my experience, realtime webApps like a multiplayer game or a chat become easier to develop and it apparently creates less overhead than using http - but still you can do the same things more or less elegant with http as well (see e.g. long polling).
Look at gmail or other existing webApps, they all use http (so does Socket.io as a fallback) and it works quite well.
I have setup a windows 2003 ftp server and using chilkat to connect to this ftp inside my customized application. My application is developed in VB6 with ftp support of chilkat. The application works on different places of the city and connects to my ftp. Unable to access ftp and transfer files using the customised application, from some networks like idea netsetter / bsnl. It works perfect on other networks.
Thanks in advance.
Regards,
Sam
This is likely to be a firewall issue at the client end. FTP is often blocked by firewalls.
Just as well, FTP has its problems making it a less than ideal alternative. There are better options such as SFTP or FTPS but support for those is limited in Windows and you'll have to buy both server and client pieces to use one of them.
Fewer firewalls block HTTP and HTTPS though some are finicky enough to block traffic that doesn't look like Web browsing. Stiil, your odds of success go up substantially.
An obvious choice might be to use WebDAV. IIS supports WebDAV and it is pretty easy to write simple WebDAV client logic in VB6 based on one of the many HTTP components available. I'd probably use XmlHttpRequest or WinHttpRequest for that. A search ought to turn up several VB6 classes written to wrap one of them to support WebDAV client operations. You can also buy WebDAV client libraries.
Stick to using HTTPS (which means you need a server cetificate for IIS) and you won't have passwords going over the network in the clear. Even if you use HTTP you'll be no worse off than using FTP, plus it'll work through the vast majority of firewalls except those that specifically block non-browsing HTTP requests.
This could be a firewall configuration on the Client or Server. You're not going to be able to do much about the client, but for the server it may depend on whether your doing Active or Passive FTP connections.
If you are doing Active connections, make sure ports 20 and 21 are open.
If you're doing Passive connections, you may want to check out this article about configuring the PassivePortRange in Server 2003 FTP- http://support.microsoft.com/?id=555022.
I've been looking to implement sending log data to a remote Syslog host from my Windows service, so far the only decent library based option I have found is the UDP remote Syslog sender in the POCO net library. I'm interested in Syslog with TLS as described in RFC 5425, which the POCO library doesn't currently support.
My question is twofold, firstly have I missed an existing implementation of Syslog for Windows that supports sending to a remote host via TCP/TLS? Secondly, if no such implementation exists, I was looking to write my own (or perhaps extend the POCO one) - it doesn't look much more complicated than establishing a secure TLS session and putting Syslog formatted text strings into a TCP socket, I would use something like the .NET TLS implementation previously discussed here for the TLS part. Have I missed something, is this not that simple? Or is the reason that I can't find any libraries that implement this sort of Syslog communication for Windows that nobody wants to do this? Am I missing the brilliant alternative to Syslog that every other Windows dev is using?
Thanks in advance.
The only packaged solution I've come across for this is from Balabit. It seems to be the only thing out there that supports TLS and RFC5425. If anyone else has come across another solution, I'd like to hear about it as well.
Nxlog can do TLS/RFC5425 and is open source. (disclaimer: I'm the author)
While it's not a library, it has several input modules to make integration easier.