Is it possible to use F5 OneConnect with non-http traffic? It seems like it might be possible to create iRules that can figure out when to attach/detach, but I haven't seen any examples.
Yes, its possible.
As per F5 AskF5 SOL7208:
The OneConnect profile may be used with any TCP protocol,
but will function only when applied to virtual servers that
are processing simple request/response protocols where
transaction boundaries are explicitly obvious, such as those
in which each request and each response is contained within
a single packet.
So it would still depend on the protocol that you want to load-balance. What protocol are you going to load balance?
Related
I created a request using a domain name, e.g., http://www.google.com. But how could I get the exactly ip address which the framework used to connect to the server?
I knew that the gethostbyname method or the nslookup method could give us the address, but since the ip address is dynamic allocated, maybe the ip address I request that time is different with these methods returned.
So is there a way for me to get the real requested ip address? (I wanted to get the ip programmatically, rather than using tcpdump, etc.)
When you say "which the framework used" here, I assume you mean NSURLSession, NSURLConnection, UIWebView, or WKWebView. Each of those is a slightly different situation, but in all of them, the answer is that it's not possible directly (but see below; it's possible indirectly). You have no access to the underlying sockets that any of them use. All of them use connection pooling, which complicates things slightly even if you could get "the socket." And in the case of UIWebView and WKWebView, a single request to www.google.com may generate several independent connections, each of which could potentially interact with a different IP address.
(I'm a bit fascinated about what you're trying to do. Due to load balancing, a single IP address doesn't mean a single server, so IP addresses are only marginally more identifying than CNAMEs. Mixing in reverse proxies....)
If you need this kind of access, you have to manage the socket yourself. That's generally possible with all of the systems except WKWebView. I'll assume that you know already (or can easily study) how to create a socket and perform HTTP using CFSocket and CFHTTPMessage. This is extensively covered in the CFNetwork Programming Guide. If you've created the socket, you can use CFSocketCopyPeerAddress to check what host you really connected to. That's the piece you wanted.
Given you are able to create this kind of socket and manage it yourself, you can hook that into the major URL loaders (except WKWebView) using an NSURLProtocol. See Drop-in Offline Caching for UIWebView (and NSURLProtocol) for a quick introduction and some sample code. You just need to take the request and make it yourself with CFSocket, giving you the chance to see the exact port you're connected to.
Your browser or whatever other tool you use to make a HTTP request will look up the address at the time of doing the request. On any reasonable system, they will use the same method for looking up the address as gethostbyname does, except that there might be local caching in the browser (which you can usually turn off or clear).
The request might get a redirection response to make the same request to a different location. These are often used for load balancing, etc. The only straightforward way I can see that you would be able to find out the 'ultimate destination' behind these, would be to make the request programmatically and record the details of any redirections, Of course, it is the nature of load balancing that you might redirected to a slightly different server each time.
This has nothing to do with 'dynamic allocation of IP addresses' by the way. If the IP address of www.google.com changes, it is likely to be not because the same server has been allocated a different IP address, but because requests are being directed to a different machine.
In case you are using NSURLSession to obtain a URLSessionStreamTask, you can capture the underlying streams using -captureStreams. This will invoke the -URLSession:streamTask:didBecomeInputStream:outputStream: delegate method, giving you a NSInputStream and a NSOutputStream. NSInputStream is toll-free bridged to CFReadStreamRef and using CFReadStreamCopyProperty() and the constant kCFStreamPropertySocketNativeHandle provides you with the native socket handle, which you can pass into getpeername(). For Upload-, Download- and DataTasks, no such possibility seems to exist.
I know that it's an unusual thing to need to do, but I need to specify the SOURCE port to be used in an outgoing http(s) request in iOS. I know that there are many different 'standard' ways to send http(s) requests -- from what I understand the most usual involve NSURLConnection and NSURLSession, but I couldn't see if I can specify the source port. Is it possible to somehow use a socket interface to create the socket and then use this socket with NSURLConnection or NSURLSession?
Or perhaps (as a hack) can one specify the ephemeral port range that my app can use (so I'll restrict it to a range of 5 or 10 ports)?
As a last grasping at straws: is there some ip masquerading or other rules that are available on the iOS device that the app could use to ensure that the source port is correct? (I suppose one could write a process which just does masquerading by hand to the correct fixed port -- essentially write a local http forwarding proxy -- is that my only possibility?)
I don't need any fancy feature or control of these http(s) requests except that they need to come from a certain very narrow range of port numbers.
thanks very much.
If you want to ask why I have such a stupid requirement, please feel free to ask privately -- but don't clutter up this question. THanks!!
I note that just a year ago, iOS: how to get the http connection's source port was asked, but that asked about READING the ephemeral port chosen by the system.
thanks
Basically, I want to implement a VoIP system with sip in a vps server. But it seems that it would not be able to handle more than ~20 simultaneous calls(just bare sip). What are the workarounds to this problem? Can the sip server be just used as a database to tell the clients where to find their intended targets..? Like p2p? I am quite new to sip. Additional info is appreciated.
Your VPS server looks to pretty low-key and when you say it cant handle more than 20 Cps that seems to indicate it topped out on CPU. Correct me if thats not the case.
Options to Scale SIP
Of the Shelf SIP Load balancer - Available in Virtual / Hardware / Opensource and every flavor that you want. It hides a farm of SIP Servers that you have and it can be managed to spread the load accordingly.
Unless the nature of SIP server is defined, it can be difficult to understand the bottlenecks you face and without that its difficult to give a simple solution.
SIP scalability comes from delegating as much work to the endpoints and doing as little on the servers as possible.
What you describe is a "redirect server": it accepts and stores registrations from the endpoints (softphones, hardphones, etc), and responds with "3xx redirect" to incoming calls and forgets about them immediately.
This is probably the most extreme example of server minimization. SIP is a very versatile protocol, it lets you set up your server infrastructure in many different ways with varying degree of control over calls. It lets you trade off features for performance.
Even the flimsiest VPS should be able to handle the signalling for way more than 20 parallel calls even in full "stateful proxy" mode.
Just make sure media (the RTP streams) is not routed through your server. Set up STUN to help firewalled endpoints send media to each other directly.
Hey SO,
What examples do you know - of protocols initially "handshaking" in UDP, then "conversing" in TCP.
I know there are heaps, I just can't seem to think of any right now.
Specifically, I'm trying to write a Wireshark dissector - for this kind of protocol.
So being able to peek on a similar dissector, seems like a good start.
Would love to hear if you've ever written a stateful Wireshark dissector in LUA.
One example is SIP/Fax.
SIP/SDP setups the session for fax transmission, and then transfers fax/image via TCP/TPKT.
There are several that use both UDP and TCP (see Apple's list, marked as TCP/UDP), but I don't know if they behave exactly as you've described (initial handshake with UDP). DNS and NFS are a couple examples.
I've written Wireshark dissectors in Lua, but not stateful ones.
Surely a handshake would be in TCP being a stateful connection? A handshake seems like something that would want to be ordered, compared to UDP where there is stateless transmission?
I've added some kind of statefulness for the HTTP protocol within my project aimed to lookup original HTTP request for given HTTP response.
Generally speaking, Lua has nice notion of closures which can be used as kind of static global variables for holding handshakes and whatever other references.
I have a server and some clients (about 50) in an intranet. The clients send short (about 40 character) string data to the server and the server answers with a similar string. There are up to (but not permanently) 2-3 requests per second for each client. The server has to serialize the requests to get the response strings.
The system should have as less as possible impact on the network as possible (i.e. the server may run something like a webserver already). It should be as easy to install and administer as possible.
What are the possibilities to achieve this using Delphi (Client: D7, Server up to D2010)?
I use the Synapse library for such a simple server. Its lightning fast, very light, and threads easily. The demo Echo in the main synapse install is a fantastic start for what your trying to do. If you are going to be performing database access inside each request/response thread then I strongly also suggest looking at the connection pool example by Cary Jensen to keep your database connections in check.
TCP, definitely. But I'd like to give a vote for ICS. Never liked Indy ...
What about Indy's TIdTCPServer and TIdTCPClient? They provide command handlers, which makes implementing text-based protocols very straight-forward.
There are a lot of options.
Ultimately, I agree with Smasher and like using sockets. They're quick, easy and portable. If you're dealing with a fairly simple protocol and don't need a full n-tier solution, creating a TCP or HTTP server application is dead simple, very light weight, and easy to make compatible with any client. You can even add SSL support to these stand alone applications without having to configure a web server or interfering with it, if it's already running on the same box.
I use RemObjects SDK for this sort of purpose. It takes care of all the difficult stuff, and I just ask it to connect and make function calls to pass the data.