Contens: a) dream about the neural net neural interface b) Can'T RemembeR... x.x Okay, what this is all about... I had a dream that I was helping someone design a percfect interface. An interface that connected two neural nets directly, one artificial and the other my own. The last thing I remember was how my mind progressed to implementation when I was in the process of waking up... it wanted the interface back! I've been working on this in the past. And while modern day scientist think the best way is to stick a few electrodes in your brain to get the neural activity, which you can then feed to an artificial neural net, I believe that there is another language that can be used just as well. Or at least I did... When devoloping ICI I believed natural lanugage was the best however... that appears flawed at this point. Natural language is hard and troublesome. I don't know anymore, we'll have to find something better. Neural relays certiantly are an option, but I suppose it would be helpful if: 1) The transport medium didn't have to be intellgent 2) We knew just what the heck was going on Ahh... finaly in days... the feeling like I'm using time efficiently and I'm only doing er... 1,2,3,... 5 things at once, heh. It seems things are comming nicely togather. I was looking at TCP/IP theory to push the limits on my dwindling bandwidth. I KNEW that there were some unused but implemented elements in both Windows and TCP/IP itself. The first little mirracle is called TCP 1323, which utilizes and enhanced TCP header which allows for bigger packets, thus imporving to signal/noise ratio. The second little mirracle has been called QoS for all eternity. Now... brace yourself to witness all of the secrets of the deep! Basically what needs to be known is the point that internet has a vast potential as it is right now, however only a very small amount of that potential is actually being used, primarily due to incomplete internet drivers and cheaply implemented routing and switching equipment. Now, what I was looking for in these internet protocols was the instructions that require to be sent allongside with the TCP/IP packets to make sure that the features required for efficient delivery of the packets get enabled. Anyway, look what I found... 1. There is an Ethernet header, this describes the source and destination MAC address (built into each network card). It also states the type of protocol following, 800 for IP. 806 for ARP (address resolution protocol). 2. Protocol header: a) IPv4 - Version (4) - Type of service: a) Delay flag b) Troughput flag c) Reliability flag d) Monetary cost flag e) Reserved flag - Packet may be fragmented flag? - Packet fragment number - Packet is last fragment flag? - Time to live - Protocol (TCP, UDP, ICMP) - Header CRC - Source and destination IPs b) ARP - Network type (1=10 mbps) - Protocol type (800=IP) - Operation code (2=ARP reply) - Sender's MAC and IP (??:??:??:??:??:?? = ???.???.???.???) - Target's MAC and IP (??:??:??:??:??:?? = ???.???.???.???; ARP request has blanks in MAC here) c) NetBIOS LLC - Destination & Source Service Access Point - Command or Request flag - Data 3. Protocol header (only after IP): a) TCP - Source and destination port - Number of uninteresting flags - Window size - CRC - Is packet urgent? b) UDP - Source and destination port - CRC - Data c) ICMP - Type (3 = Destination unreachable) - Code (3 = Port unreachable) - CRC - Unused flag - MTU in use (0 if unused) - Returned data (may be TCP/UDP packet) Now forget the point that one could forge a ARP procedure and make one of the best IP hijacks in history without even needing Windows to implement it. Take a good look at the IPv4 Type of Service headers, the TCP "Is packet urgent?" and the info provided with ICMP. ICMP is mostly blocked, but next time your are on the internet and are waiting for a 15 second timeout to occur and then find out you're not even sure what you got wrong or perhaps your program doing that, think how much faster would it all have been with ICMP. Now TCP... an online manual says "TCP supports urgent data. Urgent data is used to signal the receiver that some important message is part of the data stream and that is should be processed as soon as possible". This is the most light way to implement QoS* without killing the bandwidth. TCP 1323 also forces most internet drivers to process TCP on a packet-basis rather than killing the whole transmition when a single packet fails. And then there is IP ToS. This cannot be used on a client computer but in a network, between distribution nodes, it could be utilized to indicate when a network is being overloaded and thus help in more intelligent routing. The information however still could be present, for a user to help him diagnose when a connection is too slow, etc. * = Implementing QoS means that the control signals get priority over data flows. It is obvious, when a FTP transfer is canceled, but the cancelation can't get to the destination because it is drowned in the data being sent, that something needs to be done about that. QoS does exactly the right thing, pulling the control signals from the flood. I sincerely doubt any of these is being utilized. But who cares, sooner or later we'll all be on intelligent neural relays anyway. ;)) Joke of the day: 19. Jun @ 18 -> we have ours watercooled ^_^ 19. Jun @ 18 -> "blub"? 19. Jun @ 18 -> yah, that possible too 19. Jun @ 18 -> but the pipes are from the piping system, so its all good 19. Jun @ 18 -> me: "and what about the screens, how are those cooled?" 19. Jun @ 18 -> ;) 19. Jun @ 18 -> tech: "well in case they get too hot and catch on fire, we always have a bucket of water handy" 19. Jun @ 18 -> I was told that happened before ;P 19. Jun @ 18 -> rotflmaoshfdhjlfg 19. Jun @ 18 -> =P 19. Jun @ 18 -> ;)) 19. Jun @ 18 -> nice precautions Have fun people. =)