we work in EDI from legacy as400 system/Gentran mapping tool and we send/recieve with our EDI vendors thru VAN connection. One of our new EDI vendor ask for direct as2 connection or SFTP file transfer as they do not accept VAN due to security issues. Which should i choose - AS2 or SFTP? When there is already as2 connection and as2 certificate with our VAN, should i install seperate as2 client software for this new vendor or can i use the same connection for both? How to implement it? Note: we also use Cleo VLtrader for FTP file transfers.
You can have multiple AS2 connections out of the same software. You'll need to know their URL, their port, their certificate and AS2 ID and what security parameters they want around the connection.
They can use the same inbound connection that you have set up with your VAN.
Ultimately, both protocols are secure. Both should be "set it and forget it" for you. It's really want you want to support and maintain.
Related
I am working on a client/server program with one server (not behind NAT) and many clients that are using NAT. I need the server to be able to transfer files to the clients every so often, thus the server must be able to initiate TCP traffic when needed. I have already figured out how to do this with UDP by caching the clients' IPEndPoints and using them later.
Can anyone recommend some sample code or a project (with source) they have seen that can do this? There are lots of Chat or IM projects out there to learn from, but they generally use only UDP across NAT or only work on LANs without NAT being used. C++/C#/VB source with a solution would help a lot. Thanks.
Your best options:
Clients polls periodically to discover if new files are available. Simplest option. This may or may not scale depending on how many clients and how often they would need to poll.
All clients keep a persistent TCP connection to the server. Server sends files to a specific client when ready. Avoids the polling overhead of #1, but might have issues if the number of clients reaches into the thousands if you haven't designed your service to scale for the C10K problem.
Clients connect to a notification server which is designed to handle many clients simultaneously connected. Client sends its notification server parameters to file transfer service and disconnects. When file server has a new file available, server sends notification through notification service to tell client to connect back for an awaiting file. Client disconnects from file server after file transfer is done.
I need to develop an application which would run in a corporate network. The client should both receive commands (shutdown, restart, ...) and send info (something happened, ...) from/to the server. So, using a web interface, the network administrator would be able to see what clients are connected, send commands to them, and see real-time info coming from them. The client should be written in Delphi (normal VCL forms with Edits, etc.) and the server "preferably" in ASP.Net.
I researched a bit and I think WebSockets might be good to achieve this. I plan to use some WebSocket libraries for Delphi like this. I'm not sure what technology I should use for the server.
Please tell me if WebSockets is good for my requirements. Other solutions are welcome (maybe writing the server in Delphi?).
Web interfaces typically are HTML based views, and require a web HTTP server and a web browser (Chrome, Firefox, etc.). Delphi Web Socket client libraries however can only be used to talk with a Web Socket server from within a native Delphi application, for example a VCL GUI.
If you plan to write a VCL application (not web browser based), you have other transport protocol options besides Web Sockets, which are widely used in small and large systems:
MQTT (formerly Message Queue Telemetry Transport)
STOMP (Streaming Text Oriented Messaging Protocol)
AMQP (Advanced Message Queuing Protocol)
MSMQ (Microsoft Message Queuing)
As with WebSockets, these protocols offer asynchronous / bi-directional messaging. On the server side you can choose from many production quality implementations of these protocols (known as 'message brokers'), mostly free / open source. Similar to HTTP, message payload can be anything - text or binary data - and messages can use headers to provide application-defined metadata.
Your server-side application code can be written in Delphi, and is only another client of the message broker, communicating with the client applications over the message broker protocol. As soon as client and server are connected to the message broker, messages can flow in both directions.
Many advanced features are included in message brokers: if a client disconnects while the server is still sending messages, the message broker can store these messages and deliver them as soon as the client reconnects.
For most of these protocols I have seen client libraries or wrappers for Delphi / Object Pascal, free and open source or commercial.
We have a little problem in recognising the change we need with a FTP server getting changed to FTPS.
I want to know what will be the change we need to made to continue the current functioning of the FTP scripts .
Do we need a ssl certificate on the server which has FTP scripts running.
Do we need a client compatible to ssl on the server which has FTP scripts running.
Also please let me know if there will be any other change we need to make in FTP commands
Thanks in Advance !!!
You need a server which supports FTPS, you need a certificate so that the server can identify itself inside the SSL handshake, you need a client which supports FTPS (not SFTP, which is a completely different thing). If you need to implement the client yourself you have to implement the AUTH TLS, CCC and PROT command additionally to the existing FTP commands.
Lots of clients support FTPS, like FileZilla or lftp. For a detailled description of the new commands see RFC4217, but in essence
AUTH TLS starts the SSL handshake on the control channel so that login can be done protected
CCC downgrades the control channel to plain text again. This might be necessary for NAT traversal with helpers
PROT P defines that the data channel should also be done with SSL. Some servers enforce that the same SSL session as for the control channel has to be used.
PROT C defines that the data channel should be clear, e.g. no SSL
I've a quick question:
I have 2 websites, 1 has some links to file downloads. Those files are hosted on another server.
I need to encrypt the request data between the 2 servers..can I do it just using a SSL certificate?
Any other/better idea?
Those files are private docs, so I don't want the server 2 or any other people being able to track the file requests between the servers.
Thanks
Yes, use SSL (or actually TLS) if you want to achieve transport level security. If these are two servers that you control you can configure your own self signed certificates. If you want to make sure that only the two servers can communicate with each other, then require client-authentication, where both the server and client use a certificate/private key pair.
Most of the time the trick is to implement a sensible key management procedure. Setting up a web server to handle TLS using certificates should not be too hard.
SSL certificate will work fine for ensuring the transfer is encrypted. Even just a self signed certificate will be fine for this purpose (provided you can tell the client you're going to use to accept the self signed cert)
Alternatively if it's two linux machines then scp (secure copy) is a great tool where it'll connect via ssh and grab the files. (There probably is a windows scp tool but I don't know it)
Rsync also supports going via ssh
As for tracking the request... there's nothing you can do to prevent any device between your computer and the destination computer logging the fact a connection was made but the encryption should prevent anyone from getting to the actual data you're sending.
I'm creating a client-server game. My client is a flex based game, and my server is erlang server.
At the beginning, when I test directly my flex client in flash player, I can establish a connection easily to my erlang server through socket connection. And both can exchange data with no problem.
The problem rise when I deploy my flex app at Apache http server, and running it using a browser by calling http://localhost/ ... my flex socket sends message requesting for a crossdomain policy to my erlang server.
So I create an xml message that represent a crossdomain policy, and send it back to my flex app as a response for that request.
Yet still I can't establish any permanent socket connection between my flex client and my erlang server. I know this because I add listener on my flex socket that will modify its internal state to CONNECTED, if a connection between client-server has established.
I haven't experienced the problem but maybe this would help.
The default policy file is named
crossdomain.xml and resides at the
root directory of the server that is
serving the data...
You can use the loadPolicyFile() method to access a nondefault policy file.
http://livedocs.adobe.com/flex/3/html/help.html?content=deployingoverview_12.html
A policy file served by an XMLSocket
server has the same syntax as any
other policy file, except that it must
also specify the ports to which access
is granted. When a policy file comes
from a port lower than 1024, it can
grant access to any ports; when a
policy file comes from port 1024 or
higher, it can grant access only to
other ports 1024 and higher.
http://livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00005403.html
The flashplayer restricts your socket usage in several ways. One you already found out :) The other is to specify whether you use the network or not. There is a networking mode and a file system mode (access to the filesystem). You can't have both.
So you should try to compile it with this:
-use-network=true
And yes I know it's a PITA doing socket programming with flash. You should implement every OnErrorXYZ method and print as much information as possible. Using wireshark or a different network sniffer is also a good idea.