It seems like you should be able to use telnet to manually make json-rpc calls. However, when I try this, I get no response at all from the server and have to shut down the telnet client. Do I need to send headers and/or somehow indicate that my input is complete?
You have a small problem: you've completely misunderstood everything!
https://en.bitcoin.it/wiki/API_reference_%28JSON-RPC%29
It says right there that it supports JSON-RPC over HTTP. Nothing at all about JSON-RPC over plain TCP (what you're calling "Telnet" protocol).
You say "It seems like you should be able to use telnet to manually make json-rpc calls" but you don't mention how you came to this conclusion.
JSON-RPC is typically implemeted over HTTP, but can be implemented over plain TCP, websockets, or any bi-directional internet protocol. That being said, the overwhelming majority of JSON-RPC server implementations expose their APIs via JSON-RPC over HTTP.
As others have mentioned, you can talk HTTP from a telnet client and the payload of that conversation can be JSON-RPC.... if you know how. Just because you can doesn't meant you should.
I have a project that will let you host a Json-Rpc server over telnet if you like. It doesn't come with telnet support built in, but it would be trivial to host it over telnet. See the console hosting example and just replace the console with a telnet server.
http://jsonrpc2.codeplex.com/
Related
As far as I search, All WebRTC handshakes are done through any signaling server [ HTTP, WebSocket, etc..] even through Mail or Whatsapp.
But I expect to connect without using any of them. Is there any way to archive this?
If yes, please give me a brief solution. ThankYou!
WebRTC (as implemented in browsers) requires signalling. You can choose a different medium for signalling such as a piece of paper or calling someone on the phone, but it needs signalling.
If you want to be able to initiate unsolicited connections you need to use TCP or UDP directly which (if we ignore NAT and firewalls) don't have that restriction.
I'm writing my own simple soft phone, but I fail to understand the basics of how SIP works, so I wanted to see on a low level how a server responds to messages like the REGISTER request. I have a simple OpenWRT PBX in my router at home, and a couple of hard and Android softphones are working normally - they seem to register, perform calls both between themselves and outside too, so I'm sure it's functional. It's serving requests over UDP and port 5060.
But when I try to get a response from the server on a low level, how I used to do with tcp and telnet, just to see what's going on when a phone is working, the server doesn't seem to respond anything.
Can you please guide me how I can use netcat or some other telnet-like tool to see how the server responds over udp to any request, be them good or malformed?
Use tcpdump tool over telnet
Tcpdump Commands – A Network Sniffer Tool
check the link below.
https://www.tecmint.com/12-tcpdump-commands-a-network-sniffer-tool/
The good tool is Wireshark very good support for SIP message flow and RTP/RTCP.
You may capture the packets from the OpenWRT PBX and from your development device in order to compare things. Good learning!
I need answer to one very basic question.
Is it necessary to have telnet access to hit an API while systems are connected over VPN? For example, if my system exposed an API for other systems to hit and they are connected in VPN using IPsec, does a third party system needs telnet access to my server for using that API? The API uses soap protocol for receiving request and sending response.
(I did not find out the solution using google. The question is so naive that I had to assume everyone must already know the answer and does not bother to discuss it in web. Sorry for bothering with this simple question)
This is very strange. Accessing an http endpoint for anything else than dev using telnet doesn't really make much sense to me. If someone is using telnet to fetch informations from a server in an application. Something is already really wrong. If telnet is timing out while doing http requests. It's not really your fault and you shouldn't have to worry about edge cases like this.
If the dev is using telnet to discover security issues. This is a different issue and you could probably log anything that come from this particular client. If you gave hime some credentials, it should be easy to find who is doing which request. (I believe you might be already doing this).
You should probably ask the dev "why are you using telnet?". If for whatever reason the dev though he could send a plain SOAP request to your server using telnet without sending HTTP headers and so on.... then yes the connection is likely to timeout because the server isn't going to handle the request.
In my twisted mind, I can imagine some kind of legacy application calling scripts that open telnet sessions to parse some data and return the "parsed" data to the patched legacy project that doesn't handle http/tcp. I'd have in mind some sort of old Cobol application. Much more easier to do system call than to rewrite the whole thing to support APIs.
If for whatever reason, the client claims that telnet is needed for whatever reason. You can tell him back that telnet shouldn't be considered secure. Your api can be accessed using https. As far as I remember telnet doesn't encrypt anything unless you send encrypted data. If your client was able to hack a solution using telnet, I'm pretty sure they can hack a different solution wich use an actual http client.
WCF supports several different protocols for communicating. My WCF services are deployed on the same machine only. I just wanted to know whether TCP is more effecient than HTTP or should i go with HTTP?
If your WCF services are on the same machine, use named pipes. I've found this flow chart helpful.
.
If your service will only run on the same machine, then try using NetNamedPipeBinding.
Of course, in any case, you should measure the performance you receive using realistic test data.
The advantage of HTTP - Application layer (7 in the OSI model) - is
close to user (human) usage, via text commands (and many responses)
one can use telnet (to a port where an application dialogs via http protocol) for instance and issue some simple commands to dialog with the remote server
the http protocol deals for you with otherwise complex actions
HTTP is (usually) based on TCP (transport) / IP (Network). Thus all the advantages described above bear a performance penalty. You could define yourself an application with a more flexible protocol (at the user/application level) but it usually requires more programming, like dealing with issues that were already included in HTTP. Also, as the name protocol implies, nobody will understand your own protocol if you define one, unlike http. You'll have to design, program and build not only the server side, but also the client side. Clients will have to install your program and use it.
HTTP is built on top of TCP, therefore TCP will be definitely faster. Also HTTP has to parse the text headers which is another bunch of time spent. If your use case allows that, go with TCP.
HTTP is a protocol on top of TCP, so it's most likely faster NOT to add an additional protocol on top. See also the OSI Model.
You can clearly see that HTTP is on top of TCP here:
http://en.wikipedia.org/wiki/OSI_model
OR
even better here:
http://en.wikipedia.org/wiki/TCP/IP_model
As has been said before, TCP is the transmission control protocol, HTTP is a protocol on top. You can create your own custom protocol that could be more efficient as it would not have some of the http baggage. I had to do this to grab frame numbers from a video stream being recorded on a remote computer.
I want to write a simple SMPP Server that basically forwards traffic to another SMPP server (C#, PHP). What are the things I need to know? How do I proceed?
With regards to Goran's comment, one possible solution would be a simple tcp proxy such as simpleproxy.
From the Ubuntu package description:
simpleproxy acts as a simple TCP proxy. It opens a listening socket on
the local machine and forwards any connection to a remote host. It can be
run as a daemon or through inetd.
Olaseni,
I've done something similar in the past, but i used perl. What i did was taking a port forwarding proxy which i downloaded from accordata.com. (port-proxy.pl)
I modified this to use the NET::SMPP module to validate PDU's when reading the incoming socket. Once the PDU was of type "Bind_request" i would validate against a dbase, replace credentials if validation was successfull and than forward or if credentials were not validated, issue a reject to the client and disconnect. Alternatively if the PDU contained anything else, i would forward using the logic that was already existing in port-proxy.pl.
You can write simple smpp lib and forward smpp traffic from many applications to the one smpp connection to the sms provider
I can advice you jsmpp lib, but it's for java. It's very simple and cool lib. Many low level things happen behind the scenes and you can focus on your business logic
Find more here
I have written exactly what you are asking for in vb.net
What i did was listen for inbound PDU (connect, bind, sms, and disconnect too) identifying each inbound connection uniquely - for the authentication bit,
then i forward the traffic onward to the delivery smsc.
Your SMPP service simply needs to listen for inbound PDU packets... as well as send heartbeat packets to the connected clients, if required.