Is that possible to force the ServerXMLHTTP to connect to internet through an existing windows socket?
For some reasons, I'm using VB6 winsock control and the winsock connected to a certain PC. I want to communicate with that PC in SSL protocol, but I need to implement too much thing to make winsock work properly like ServerXMLHTTP.
So, yes or no, can I force the ServerXMLHTTP (or event WinInet) to work using existing windows socket?
Here are a few options for implementing the SSL protocol with access through VB6/COM interfaces.
Expose COM interfaces around .NET Framework custom code and libraries for encryption and then call your .NET created COM interfaces from your VB6 application.
Utilize an off-the-shelf component that already has the SSL protocol implemented for you.
Implement the full SSL specification in VB6
After clarification about the need to use an "existing windows socket" I'll update the answer with more details.
Related
I'm trying to implement a sip server for connecting to from an HTML sip client(made using sipml5). During my research into doing this I've come across sip over web-sockets which might be useful to me, however, I am unsure if a user agent connecting through sip over web-sockets to a compatible server would then be able to successfully make a call to some one using an incompatible server(i.e. calling from SIP over web-sockets to true SIP).
I know webrtc2sip can be used for connecting to legacy networks but I would rather avoid using another proxy if at all possible. So, is it possible to connect to a compatible SIP server using SIP over web-sockets then make a call from this user agent to another that does not support SIP over web-sockets without using a gateway?
You are right, SIP over Websockets is a draft, not specification. And I do not know many SIP vendors who support this draft.
Possible solution is truly websocket-SIP gateway. For example Flashphoner Web Call Server is implemented as a gateway which works through websockets with browser and works via SIP(TCP and UDP) with SIP servers. Therefore it is compatible with any server that supports RFC3261 - standard SIP specification.
Brief signaling scheme is:
Browser - [Websockets] - Web Call Server - [SIP TCP, UDP] - any SIP Server
Brief streaming scheme:
Browser - [WebRTC = SRTP, DTLS, ICE, STUN ] - Web Call Server - [RTP UDP] - any SIP/RTP Server
An alternate way is to use kamailio as it understands both sip and ws sip .
when you say "implementing a sip server " is it a simple registrar or proxy server or you want cal control logic / presence other features ?
In all cases kamailio fulfills all requirements , plus it is opensource .
Mobicents SIP Servlets Example already provides a B2BUA Application taking care of that for you. The Media is peer to peer (or through a TURN Relay Server) but if you need to bridge to a Media Server, you can indeed patch the SDP Body to make the media of each party go through the Media Server (pending it supports Media related codecs from WebRTC, DTLS-SRTP etc) to add conferencing, recording type of capabilities.
Has anyone here tried connecting to the MindWave device through the COM port associated with the bluetooth device? Is it better to just connect through the Thinkgear Connector? My target language is Ruby and I was thinking of using the serial-port library.
If you connect to the serial port directly you will have to parse binary data which, actually, ThinkGear Connect socket protocol is for (all related is here) TGSP is JSON-based protocol so dealing with it in Ruby is piece of cake (below is an extract from documentation at the link above)
ThinkGear Socket Protocol (TGSP) is a JSON-based protocol for the
transmission and receipt of ThinkGear brainwave data between a client
and a server. TGSP was designed to allow languages and/or frameworks
without a standard serial port API (e.g. Flash and most scripting
languages) to easily integrate brainwave-sensing functionality through
socket APIs.
So I'd suggest you deal with TG socket protocol (I assume you don't run Ruby on an embedded device, for if you do, you will definitely need to parse data from TGAM chip by hand) rather than parse on your own, but don't forget you will have to have ThinkGear Connector software up and running everywhere you wish your code to run at.
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.
I'm in the process of porting an application to the Windows Phone platform. I spent quite a while reading MSDN documentation and I can'd find nothing on the subject.
Is it possible to create server sockets on Windows Phone? All I've found is related with client side, like creating connections to remote machines. I can't find nothing the other way: The phone acting as the server.
Some essential methods like Bind and Listen are not exposed by the Socket class included in the Windows Phone 7.1 SDK.
This was kind of a surprise to me.
Any help or confirmation on this will be truly appreciated!
Thanks in advance!
You cannot open a socket for listening from a Windows Phone 7 application. This is due primarily to the complexities of the cellular data networks, such as the use of transparent proxies, shared IP addresses, and frequent connection disruptions.
Until windows phone 8 you will not be able to listen on sockets, you have to use an intermediary service to listen/send between two or more phones.
Check this link, on windows phone 8, there is new API introduced for streamlistner
We are also trying at our end, should be possible
Class is StreamSocketListener
http://msdn.microsoft.com/en-us/library/windowsphone/develop/windows.networking.sockets.streamsocketlistener.aspx
I dont know about a "server" but it has UDP functionality and can send data through it and send/receive with TCP.
also, i have found the SDK to lack some APIs to interface with the phone. ex no Bluetooth or not being able to switch between internal and headphones for sound through developer programming.
I'm trying to port a win32 application to Windows Mobile 6 / 6.1 / 6.5. It uses winhttp which doesn't appear to be available on the mobile platforms.
My initial thought was to replace it with WinInet - but I wondered if anyone had a better idea?
WinInet is actually a more appropriate HTTP client library for client nodes.
Here's some things I like about WinInet voer WinHttp:
If your client app needs to make lots of requests from the same server, WinInet will implicitly queue the requests up so as not to flood the server. (But is transparent to the client app). In other words, it respects RFC 2616 guidelines on simultaneous connections. This is great when your app is pulling down a lot of images (or files) from the same server simultanously.
Will the use the IE cache for fetching content. (Which I assume an equivalent cache exists on Mobile platforms).
Proxy server auto-detected from IE settings. Probably less of an issue with mobile since the IP network is a bit more open. But if you had to support proxy servers with WinHttp, you'd have to use other API calls to specify the server directly.
I've used Wininet and it works. But it's not ideal as its timeouts are broken. And developing a complete asynchronous design with it required a ton of code.
So instead, I'm trying libcurl.
So far though, I still haven't managed to get it compile properly and link. Porting stuff is such a pain sometimes. But I digress. ;)